User:Pingou/GatingRawhide

Rawhide Gating

When considering gating rawhide package updates on test results, we need to consider two workflows: single package updates, multi-package updates. Both of them are presented here.

Scope

The scope of this work is adding a mechanism to gate package before they enter the rawhide buildroot (and thus become accessible to others) so broken packages are kept out and cannot affect other packages or the compose until they are fixed by their maintainers.

The CI system and the tests are out of scope for the present document.

People involved

• pingou (point of contact)
• <more to come>

Workflows

<single package update>

<multi package update>

Workload

Bodhi

• Single package update
  • We will need to write a message-bus listener that will automatically create a bodhi update for each package built in the rawhide-gated tag.
  • We will need to write a message-bus listener to automatically push bodhi updates created for rawhide that have passed CI (the decision being announced by Greenwave).

• Multi package update
  • We will need to allow bodhi to create a new update from a specified side-tag instead of a list of builds.
  • We will need to write a message-bus listener that, upon greenwave notifications about an update created from a side-tag passing CI, will move all of its builds into the rawhide-candidate tag and clean the side-tag created for this update.
  • We will need to write a script that regularly clean old side-tags left around

Koji

• We will need a koji plugin allowing packagers to create new side-tags

fedpkg/rpkg

• We will need to add support for the command: fedpkg side-tag create which will create a new side-tag in koji for this user using the new plugin

• We will need to add support for the command: fedpkg side-tag merge which will call bodhi to ask it to create an update corresponding to this side-tag
  • Alternatively: Expand the existing fedpkg update command to add support for creating a new update from a side-tag

Greenwave / WaiverDB

Nothing should change for these tools but we will have to confirm this and test in staging that they behave as expected.

CI system

Nothing should change for the CI system but we will have to confirm this and test in staging that they behave as expected.

User experience

Single package update

   fedpkg clone rpms/foobar
   cd foobar/
   vim foobar.spec
   git commit -am "Git commit message"
   fedpkg build
   

If the CI tests pass, the package will land in rawhide, if they fail the user will be able to go to bodhi to see what failed and why as well as waiving the failed tests if needed.

Multi package update

   fedpkg clone rpms/foobar
   cd foobar/
   fedpkg side-tag create foo1.2
   vim foobar.spec
   git commit -am "Update of foobar to update foo to 1.2"
   fedpkg push
   fedpkg build --target=user_foo1.2
   cd ..
   fedpkg clone rpms/foobaz
   cd foobaz
   vim foobaz.spec
   git commit -am "Update of foobaz to update foo to 1.2"
   fedpkg push
   fedpkg build --target=user_foo1.2
   cd ..
   fedpkg clone rpms/foo
   cd foo
   vim foo.spec
   git commit -am "Update foo to 1.2"
   fedpkg push
   fedpkg build --target=user_foo1.2
   fedpkg side-tag merge foo1.2

If the CI tests pass, the package will land in rawhide, if they fail the user will be able to go to bodhi to see what failed and why as well as waiving the failed tests if needed.

Benefits to Fedora and the community

• As more packagers opt-into gating and add tests to their packages, rawhide becomes more stable

• More stable rawhide will lead to easier composes and a smoother release process

• Ability to use chain-build in rawhide and stable releases

Costs to Fedora and the community

• Slight changes in the packager workflow in the case of multi-packages updates