Single Build Updates
The initial release of Rawhide Gating is exlusively for single build updates. This release is going live in July 2019.
What are Single Build Updates?
Single build updates are updates containing one build which doesn’t tightly depend on other build(s) and therefore can be processed safely in isolation.
For example, the package rpms/pass is a simple bash script bundled with some documentation and utilities (for emacs, vim or zsh). It depends on git, gnupg2, perl-generators and tree to build and xclip in addition to these for running. It doesn’t depend tightly on the specific version of any of these (it only has a minimal required version for tree). It does not rely on any ABI, does not need to be rebuilt on soname changes or updates.
Packages of that style are candidates for single build updates. They can be built and tested by themselves.
How Does Gating Single Build Updates Work?
Single build updates are easy to gate since they can be tested in isolation from the other builds. That is, the CI system can take the build, test it, gate it or let it pass through, without having to consider any other changes (i.e. packages/builds).
The workflow is as follows:
When you build your package for Rawhide, it lands in a default Koji tag (the candidate tag:
Bodhi will be notified of your build landing in that Koji tag by our message bus. It will automatically create an update for this build, on your behalf. The update will start out in the
Pendingstatus and the build will be moved to
RoboSignatory is notified that your build landed in this tag by our message bus, it will take the build, sign it and move it to the
Bodhi is notified that your build was signed and moved to this tag by our message bus, it will mark the build as signed and move the update to the
Tests will be run, their results will be reported to ResultsDB which will announce these results, making Greenwave consult your
gating.yamlfile to see if all the required criteria of this build have been met or not. If they have, Greenwave will send a message to the message bus announcing its decision.
Bodhi will listen for these messages from Greenwave. Upon receiving them it will push the corresponding build into the final Koji tag (i.e. the stable tag) and mark the update as
At this point, your build has landed in the stable tag in Koji, it is therefore available in the buildroot for anyone to use and rely on and the corresponding Bodhi update has been marked as stable.
Note that the update being
Want to help? Learn how to contribute to Fedora Docs ›