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: -updates-candidate).

  • 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 Pending status and the build will be moved to -signing-pending tag.

  • 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 -updates-testing-pending tag.

  • 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 Testing status.

  • Tests will be run, their results will be reported to ResultsDB which will announce these results, making Greenwave consult your gating.yaml file 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 Stable.

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 stable does not mean you will be able to install it via dnf/yum. It means the build is available in the Rawhide buildroot. It will be pushed to the mirror once the next Rawhide compose succeeds.

Simplified diagram of the single build updates workflow

Simplified single build update

Want to help? Learn how to contribute to Fedora Docs ›