One of the main topics discussed at the CentOS Connect in Brussels last week was the ability for third-parties (for example RDO or IdM teams) to contribute test results to the Compose Gate of the CentOS Stream so that they can prevent regressions on CentOS Stream packages before they hit the public mirrors.
Currently we run the so called t_functional test suite in the Compose gate, which can be extended by contributing your own test cases (the TMT version of the test suite is being developed in CentOS / Integration SIG / compose-tests · GitLab)
Thus we’d like to provide the ability for third-parties to get the latest nightly compose, test it on their own environment and contribute test results back to the CentOS RelEng team.
Technically speaking main pieces for this workflow are already available:
nightly composes are published in the open at Index of /production/latest-CentOS-Stream/compose and the message is sent to Fedora Message Bus or can be picked from the Testing Jenkins API, but it does not provide the visibility and requires custom tooling.
During the CentOS Integration SIG Meetup we discussed that we’d like to provide the Git interface to the Compose gate so that each new compose is represented as a new Merge Request to a Git repository.
There is a new git repository (Compose Repo), in the Integration SIG space.
- New compose is created by the CentOS Stream Infra
- Automation is triggered by the new compose event. It generates new Merge Request to the Compose Repo (the content of the MR is TBD, but it can be for example a list of NVRs included in the compose)
- Third-parties watch for the new merge request in the Compose Repo and trigger their own tests on the new compose
- Once they are done with the testing, they report test results on the Merge Request via votes/labels/comments/TBD…
- As soon as compose is verified and tested, we promote it to be published to the CentOS Mirrors
- Automation recognizes the publishing event and merges the relevant Merge Request to the repository
On the first iteration we will use Git repo only as a representation of the existing pipeline which runs in the background. The Merge Request will be created slightly after the compose is built by the build system and merged slightly after the compose is pushed to the mirrors.
This way we can play with the idea on the side without disrupting the main compose workflow.
Once we figure out the format for Merge Request and Compose Repo content, we may eventually switch the workflow so that Merge Request becomes the main entry point for the compose pipeline.
This is currently the outline of the idea.
We will track the work on this topic in the dedicated Epic in the CentOS Integration SIG GitLab space.
Please join us bringing your feedback, questions, suggestions and, of course, contributions