The OpenLab CI is built based on
Zuul tools of the OpenStack infrastructure. The CI jobs definition uses Ansible playbooks. Learn more about the tools first:
Zuul documentation is hosted on Zuul
NodePool documentation is hosted on NodePool
Ansible documentation is hosted on Ansible Docs
The accepted test requests can be found in TODO list, developers can get start with following steps:
Pick one test request you wish to work on, move it to IN PROGRESS list, edit it to add the development plan into comments
Fork your own copy of the CI job repository openlab-zuul-jobs to your account, develop the test job and submit a PR(Pull Request) to openlab-zuul-jobs. In order to manage the test request well, please add change details and link the test request number in PR's commit message, the format like:
OpenLab development team @theopenlab/dev will review the PR and give some suggestion, development core team @theopenlab/dev-core have permission to merge it if there is no issue, at the meanwhile, you should contact @theopenlab/dev-core to add the target project into main.yaml in zuul node if it is not in project list of zuul
When your PR is merged into master of openlab-zuul-jobs, trigger to test the integration job by trigger comments, see the build status, click result
FAILURE enter the build web page and then click the
log url to get the log details if the job fail. Maybe you can find some problems of job, feel free to submit new pull request to openlab-zuul-jobs to fix job issue, link the issue number of related test request in PR's commit message as we do on step3
In Progress test request by yourself when the work completely, notify @theopenlab/governance and @theopenlab/docs to update website and documents in RP comments.
If your test request need some physical machines, please contact @theopenlab/governance members in IRC channel or send them an email, they will help you to get OpenLab dedicated resources to launch testing
When you can access the physical machines, move your test request to IN PROGRESS list, edit it to add the development plan into comments
When the work is completely, close the
In Progress test request by yourself, please commit the test result into comments of test request related issue. A blog also is a good choice to show more details of testing. Notify @theopenlab/governance and @theopenlab/docs to update website and documents in RP comments.
Features and bugs for OpenLab are tracked in issue list
Perhaps the merged CI job will fail due to some reasons after it has been running for some time, or if you find any other enhancement points or problems of OpenLab, welcome to new an issue
The development core team @theopenlab/dev-core will confirm the feature or bug, add them into TODO list
Submit a PR(Pull Request) to openlab-zuul-jobs to implement feature or fix bug, please add change details and link the issue number in PR's commit message:
OpenLab development team @theopenlab/dev will review the PR and give some suggestion, development core team @theopenlab/dev-core have permission to merge it if there is no problem. When the PR is merged into openlab-zuul-jobs, you can test jobs by trigger comments
In Progress feature or bug by yourself when feature is implemented or bug is fixed.
When we implement an integration test request, usually we need to add new job into openlab-zuul-jobs. To unify the job name format, we have the following naming notations:
The project usually is the name of the git repository which contains tests to run.
The test type is the type of tests to run, e.g. acceptance test, integration test, functional test, unit test.
The backend is the test environment provider, include: deploying tools, public cloud, private cloud,
e.g. devstack, kubeadm, minikube, VEXXHOST, optionally, default is
The service is the specific backend service which this job will run against, optionally, default is
The version is the specific backend version which this job will run against, optionally, default is
For an example, the job definition about running the specific Trove related acceptance tests of terraform-provider-openstack repository can be named as:
And running Spark integration test against Kubernetes 1.13.0 that is deployed by minikube:
OpenLab manage lots of periodic jobs for many projects, these jobs will be triggered by OpenLab CI to execute testing and collect result in everyday. For decreasing OpenLab resource usage, we should split all of periodic jobs into each pipeline as evenly as possible, and avoiding concurrent jobs with same test target affect each other, like: public cloud tenant, for example, lots of periodic jobs run to create instance in same public cloud tenant, that will hit tenant quota limit. So there are three basic principles to help you to decide which pipeline when you want to add new periodic job:
Split the jobs have same backend(public cloud account), like: VEXXHOST, OpenTelekomCloud or HuaweiCloud into different pipeline to avoid influencing each other. Job backend is local deployed OpenStack, Kubernetes and other, that is OK in same pipeline.
Split all of periodic jobs into each pipeline as evenly as possible.
Choose the trigger time you like.