CI-Pipeline Architecture and Design
In this section we will describe the different steps that the pipeline aims to introduce and support.
0. The packager opts into the pipeline for one or more packages and agrees the tests of these packages will be gating their push to the Fedora repositories.
- The tests are contained in dist-git repos and can be invoke via Ansible following the Changes/InvokingTestsAnsible proposal.
- The packager should be able to opt into which tests and test suites gate their package.
- Goal: eventually all packages involved in Fedora Atomic Host will have opted into the pipeline.
1. The pipeline starts after a packaging change is pushed to dist-git repo
- The change is composed of one or more dist-git commits.
- The change is what we is tested in the pipeline against the known-good (already merged) set of changes.
- Requirement: This dist-git commit should not yet affect other packagers.
2. The package is built with the new change
- The build occurs in Jenkins using Mock.
- This is a temporary solution until we find the appropriate way to have test builds in koji
- If the package contains a %check section calling the unit-tests, these are run
- Send build result on the fedmsg bus
3. The package built is pulled into a compose
- The build occurs in Jenkins
- Integration tests are run against this compose
- Send test results on the fedmsg bus
4. The packager builds the package in koji as usual
5. The packager creates the bodhi update as usual
6. Gating happens in bodhi
Build result and test results are gathered in Bodhi.
If a test passes CI then that change is allowed through Bodhi. At this point the change starts to affect further development. This results in future changes going through CI being layered on top of this change.
If any tests fail, then the change will not be allowed through Bodhi (packager will be notified of failures), and no later runs of CI will include the change. A different change would then be run through the pipeline.