CI-Pipeline Architecture and Design
In this section we will describe the different steps that the pipeline aims to introduce and support.
Stage 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.
Stage 1. Trigger: The pipeline starts after a packaging change is pushed to dist-git repo
- Once packages are pushed to Fedora dist-git this will trigger a message. (fedmsg and Jenkins integration is via the Jenkins JMS Plugin)
- The change is what we is tested in the pipeline against the known-good (already merged) set of changes. The pre-merge is covered in "Stage 0", which is a CI inner loop that is a Pull Request workflow.
- Only Fedora Atomic Host packages will be monitored for changes.
- Requirement: This dist-git commit should not yet affect other packagers.
Stage 2. The package is built with the new change
- The build occurs in Jenkins using Mock. We may leverage COPR in the future for builds
- Once the pipeline is triggered as part of the build process if unit tests exist they will be executed.
- The end result is package will be produced to then be used for further testing. Success or failure will result with a fedmsg back to the Fedora reviewer/maintainer.
- Send build result on the fedmsg bus can be integration to any Fedora tools.
Stage 3: Functional Tests on Package
- Functional tests will be executed on the produced package from the previous stage of the pipeline if they exist. This will help identify issues isolated to the package themselves. Success or failure will result with a fedmsg back to the Fedora reviewer/maintainer.
- Send build result on the fedmsg bus can be integration to any Fedora tools.
== Stage 4. 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.