{"id":37677379,"url":"https://github.com/openstack-charmers/zosci-config","last_synced_at":"2026-01-16T12:17:09.883Z","repository":{"id":37782249,"uuid":"327032070","full_name":"openstack-charmers/zosci-config","owner":"openstack-charmers","description":null,"archived":false,"fork":false,"pushed_at":"2025-04-02T22:19:43.000Z","size":870,"stargazers_count":1,"open_issues_count":9,"forks_count":18,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-04-02T23:24:58.750Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openstack-charmers.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-01-05T14:59:13.000Z","updated_at":"2024-12-16T17:17:10.000Z","dependencies_parsed_at":"2023-02-17T17:46:07.178Z","dependency_job_id":"302ec8d3-522d-40a7-a190-3754a2e16a86","html_url":"https://github.com/openstack-charmers/zosci-config","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/openstack-charmers/zosci-config","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack-charmers%2Fzosci-config","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack-charmers%2Fzosci-config/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack-charmers%2Fzosci-config/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack-charmers%2Fzosci-config/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openstack-charmers","download_url":"https://codeload.github.com/openstack-charmers/zosci-config/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openstack-charmers%2Fzosci-config/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28478539,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-16T11:59:17.896Z","status":"ssl_error","status_checked_at":"2026-01-16T11:55:55.838Z","response_time":107,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-16T12:17:07.062Z","updated_at":"2026-01-16T12:17:09.869Z","avatar_url":"https://github.com/openstack-charmers.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# OSCI using Zuul\n\nTo use Zuul in place of Jenkins for Ubuntu's OpenStack CI (OSCI), it's worth\nstarting with a basic evaluation of what tasks OSCI currently performs for us\nand ensuring that we can do the same things with Zuul. There are a few\ndifferences depending on if a charm is reactive, classic, or other (such\nas operator); however, we can generally summarize them the same:\n\n1. lint\n1. unit tests\n1. (optionally) build the charm\n1. (optionally) lint built charm\n1. (optionally) unit test built charm\n1. run zaza on a deployable charm\n\nThe last line above deserves special attention. With OSCI, the last step is\nperformed with the `func-smoke` or `func` `tox` targets, asking Zaza to run\nthe whole test suite in series, for example: \n\n```\nbionic-stein -\u003e bionic-rocky -\u003e bionic-queens\n```\n\nIn addition to the test lifecycle above, OSCI Jenkins also performs release\nrelated tasks such as publishing artifacts to the charmstore and scheduled\nversions of the above as well.\n\nWith Zuul, we can configure the functional testing to be performed in a more\nparallel fashion, with steps optionally depending on a step before them. For\nexample, it's possible for us to have jobs defined such that a `charm-build`\njob is performed before a `func-test` job. In addition, jobs would be defined\nin a more centralized fashion, by default, without restricting our ability to\ndefine jobs in a specific repo.\n\nZuul can run scheduled tasks as well, so we should be able to replicate our\nregularly scheduled test runs as desired.\n\nIt is possible for us to define pipelines for different parts of the change\nlifecycle, so that we could add a job to Zuul to publish resources after the\nchange has landed upstream but that hasn't been encoded in this evaluation.\n\nTo further explore what this looks like, the following sections will describe\ncommon tasks that must be performed and what they look like for both Jenkins\nand Zuul.\n\n## Example tasks\n\n### Add a new release combination\n\nTo add a new release combination to a charm under our traditional Jenkins,\na developer must touch every charm to add a new line into `tests/tests.yaml`\nso that Zaza will add it to the test matrix for that charm. With Zuul, we can\neasily have a [centralized location](./zuul.d/project-templates.yaml) where we\ncan define common jobs. Adding a new release combination to our Zuul tests is\nas easy as adding the new item to the default jobs that we run for every charm.\n\n### Adding a secret\n\nPlace the secret in a file and use zuul-client to generate the configuration\nsnippet for you:\n\n```\n    ZUUL_API_EP=X.X.X.X\n    NAME_OF_KEY=\"ldap_secret\"\n    echo \"My secret\" \u003e /tmp/secret\n    zuul-client --zuul-url http://${ZUUL_API_EP} encrypt \\\n        --project 'github.com/openstack-charmers/zosci-config' \\\n        --tenant openstack --infile /tmp/secret  \\\n        --secret-name ${NAME_OF_KEY} --field-name value\n```\n\nThe snippet can then be added [secrets config](.zuul.d/secrets.yaml). For more\ninformation see\n[zuul encryption](https://zuul-ci.org/docs/zuul/discussion/encryption.html)\n\n### Run a functional test\n\nWhen a developer wants to test their changes in OSCI, the current setup\ndefaults to just running a smoke test. One downside of this is that all\nsupported release combinations aren't tested for every change; however, it\ndoes allow us to get test results on a change reasonably quickly (around an\nhour, generally).\n\nWith Zuul, the approach would be to define the functional test jobs so that\nthey can be run in parallel, but that they should use a `Semaphore` from Zuul\nto control concurrency. This would allow us to control the number of automated\nmodels that are being created at once with a fair degree of accuracy.\n\n### Retry a failed functional full test\n\nWhen a single test failed in a recheck-full, that failure blocks all other\ntests from completing, as well as being impossible to retry directly, so a new\nrechec-full is required which may fail on a different deploy. There are many\npotential causes of transient failure with a Juju model deploy, so this can be\na difficult process to work through.\n\nWith Zuul, it's possible, and enabled by default, to have jobs be retried.\nAlong with the ability to configure each job independently, this means that\neach of our functional test models would be allowed to retry by default,\nhelping us to reduce the need for full retries to resolve a transient test\nfailure.\n\n### Add a custom test to a charm\n\nTo add a custom test to a charm is, with Jenkins, similar to adding a new\nrelease combination, except it's just for a single charm. Adding a new test\nto a specific charm in Zuul is fairly similar, except that it needs to be added\nto the charm's local zuul configuration file. An example of a custom job is:\n\n```yaml\n- job:\n    name: focal-ussuri-ec\n    description: |\n      Run a functional test. This test is defined in the\n      ceph-mon charm itself.\n    parent: func-target\n    vars:\n      tox_extra_args: '-- focal-ussuri-ec'\n```\n\nThis job was taken from the ceph-mon charm to ensure that we can use both\ncentrally defined jobs as well as charm-local jobs to customize the tests.\n\n## Adding Zuul OSCI support to a charm\n\nTo add support for the new Zuul to a charm is a fairly simple process.\nFirst, the charm should be added to [projects.yaml](./zuul.d/projects.yaml) in\nthis repository. After that, a new file to configure the charm should be added\nto the charm in question, named `osci.yaml`. An example that can be used as a\nguide for any charm is:\n\n```yaml\n- project:\n    templates:\n      - charm-unit-jobs\n      - charm-functional-jobs\n```\n\nThe above configuration will run the named\n[project-templates](./zuul.d/project-template.yaml) which, currently, would\nrun the following unit test type jobs:\n\n```\n- osci-lint\n- tox-py35\n- tox-py36\n- tox-py37\n- tox-py38\n```\n\nand these functional jobs:\n\n```\n- focal-wallaby\n- focal-victoria\n- focal-ussuri-ec\n- focal-ussuri\n- bionic-ussuri\n- bionic-train\n- bionic-train-with-fsid\n- bionic-stein\n- bionic-rocky\n- bionic-queens\n- xenial-queens\n- xenial-pike\n- xenial-ocata\n- xenial-mitaka\n- trusty-mitaka\n```\n\nWith the above defaults, as well as charm-specific configuration to enable\nthe custom test requirements, Zuul shows us the following for the ceph-mon\ncharm:\n\n![zuul-ceph-all-jobs](images/zuul-ceph-mon-all-jobs.png)\n\n## Reporting on Gerrit\n\nWhen Jenkins reports a test failure on Gerrit today, we can see the results\nof the unit and lint tests, but all of the functional tests are treated as an\nopaque blob to gerrit.\n\nWith Zuul, the reports to Gerrit include each job that is run, allowing us to\nsee granular results:\n\n![gerrit-zuul-report](images/gerrit-zuul-report.png)\n\nThe above results were posted after a partially successful run of a subset\nof the Ceph example above:\n\n![zuul-ceph-mon](images/zuul-ceph-mon.png)\n\n## Potential improvements\n\n### Per test OpenStack tenant\n\nThere are some possible improvements over the current example presented here,\nincluding potentially creating a new OpenStack tenant for each functional test.\nBecause we control the test environment via ansible, it would be possible to\ncreate a tenant in the setup stages of a functional test, and remove that\ntenant's resources and the tenant itself in a cleanup stage.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenstack-charmers%2Fzosci-config","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenstack-charmers%2Fzosci-config","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenstack-charmers%2Fzosci-config/lists"}