Project Testing Interface
The following sections describe an example PTI (Project Testing Interface) implementation. The goal is to setup a consistent interface for driving tests and other necessary tasks to succesfully configure Project Gating within your organization.
A proper PTI needs at least two projects:
org-config: a config-project curated by administrators, and
org-jobs: a untrusted-project to hold common jobs.
The projects that are being tested or deployed are also untrusted-project, and for the purpose of this example we will use a couple of integrated projects named:
The config project needs careful scrutiny as it defines priviledged Zuul configurations that are shared by all your projects:
Pipeline triggers and requirements let you define when a change is tested and what are the conditions for merging code. Approval from core members or special labels to indicate a change is good to go are pipelines configuration.
The base job let you define how the test environment is validated before the actual job is executed. The base job also defines how and where the job artifacts are stored.
More importantly, a config-project may enforce a set of integration jobs to be executed on behalf of the other projects. A regular (untrusted-project) can only manage its own configuration, and as part of a PTI implementation, you want to ensure your projects’ changes undergo validation that are defined globally by your organization.
Because the nature of those configuration settings are priviledged, config-projects changes are only effective when merged.
Jobs definition content are not priviledged Zuul settings and jobs can be defined in a regular untrusted-project. As a matter of fact, it is recommended to define jobs outside of the config project so that job updates can be tested before being merged.
In this example, we are using a dedicated org-jobs project.
In this example PTI, the organization requirements are a consistent code style and an integration test to validate org-client and org-server works according to a reference implementation.
In the org-jobs project, we define a couple of jobs:
test_command: $code-style-tool $org-check-argument
# e.g.: linters --max-column 120
The integration-tests.yaml playbook needs to implement an integration test that checks both the server and client code.
In the org-config project, we define a project template:
Finaly, in the org-config project, we setup the PTI template on both projects:
With the above layout, the organization projects use a consistent testing interface. The org-client or org-server does not need extra settings, all new contribution shall pass the codestyle and integration-test as defined by the organization admin.
Projects may add extra jobs on top of the PTI. For example, the org-client project can add a user interface test:
In this example, new org-client change will run the PTI’s jobs as well as the org-client-ui-validation job.
Updating PTI test
Once the PTI is in place, if a project needs adjustment, it can proceed as follow:
First a change on org-jobs is proposed to modify a job. For example, update a codestyle check using such commit:
Update codestyle to enforce CamelCase.
Then, without merging this proposal, it can be tested accross the projects using such commit:
Validate new codestyle.
Lastly the org-jobs may be enriched with:
Update codestyle to enforce CamelCase.
Extra care is required when updating PTI jobs as they affects all the projects. Ideally, the org-jobs project would use a org-jobs-check to run PTI jobs change on every projects.
Cross project gating
The org-pti template is using the “integrated” queue to ensure projects change are gated by the zuul scheduler. Though, the jobs need extra care to properly test projects as they are prepared by Zuul. For example, the org-integration-test playbook need to ensure the client and server are installed from the zuul src_root.
This is called sibling installation, and it is a critical piece to ensure cross project gating.