On July 25th we will turn on the first phase of Rawhide package gating: single build updates. In a later phase, Rawhide updates that contain multiple builds will also be enabled for gating. Our goal is to improve our ability to continuously turn out a useful Fedora OS. So we hope and expect to get opt-in from as many Fedora package maintainers as possible, including maintainers of the base OS. But this phase of gating remains opt-in, and should not affect packagers who choose for now not to opt in.

Last April FESCo approved a change proposal allowing to gate Rawhide packages based on test results. The proposal included gating updates with only a single build as well as updates with multiple builds. It was designed to cause minimal to no interference with the current workflow of packagers who do not opt-in.

The team has been working hard on this proposal, and decided to do a phased roll-out of this change, so that we can gather feedback as early as possible from the packagers interested in testing this workflow without impacting everyone.

On July 25th, we plan to turn on the first phase of this change.

What does it mean for packagers?

When you run fedpkg build on Rawhide, your package will be built in a new koji tag (which will be the default target for Rawhide). The package will be picked up from this koji tag, signed and moved onto a second tag. Bodhi will be notified by koji once this new build is signed and will automatically create an update for it (you will be notified about this by email by bodhi directly) with a “Testing” status. If the package maintainer has not opted in into the CI workflow, the update will be pushed to “Stable” and the build will be pushed into the regular Rawhide tag, making it available in the Rawhide buildroot, just as it is today

If the package maintainer has opted in into the CI workflow, the creation of the update will trigger the CI pipeline which will send its results to resultsdb, triggering greenwave to evaluate if all the required tests have passed or not, thus allowing the update to go through the gate or not.

This is the first roll-out of this gating change, and so there may be additional tuning and fixes until things are as smooth as we want them to be. With this release we are looking for feedback on what can be improved. We have a dedicated team working on this project and we will be taking your feedback into account to improve the experience.

Small FAQ:

But I do not want to use gating!

While we believe CI and gating will ultimately help making a better Fedora, there is nothing enforced at this point. Keep packaging as you do now!

How do I enroll?

Great! We’re glad to see such enthusiasm! You can find the instruction in the docs on how to enable gating.

It does not work!

Bugs will be bugs. This is the first roll-out of this change, and more will come. This rollout lets us gather feedback and iterate on the approach in an open source fashion.

If you did not opt-in and you can’t do your packaging work as you used to, please file a infrastructure ticket, since it’s likely a bug.

If you did opt-in and something in the gating of your update doesn’t work (for example, CI ran but its results aren’t being considered, waiving didn’t work…), file an infrastructure ticket.

If you opted-in and the tests don’t run the way you expect, file a fedora-ci ticket.

I enrolled but now I want to step out for some reason

:sad trombone:

We hope you reported (see previous answer) all the issues you’ve found/faced and are helping us resolving them. In the meanwhile, you can simply remove the gating.yaml file you’ve added in your git repo and that should be enough to make greenwave ignore your package.

Another question

Want to know more? Your question isn’t here? Check our docs on rawhide gating! We’ll keep it up to date as we face or solve questions.