m (Pingou moved page Changes/GatingRawhidePackages to Changes/GatingRawhideSinglePackageUpdates: We're splitting this proposal into two) |
(Updated proposal) |
||
Line 1: | Line 1: | ||
= Gating Rawhide = | = Gating Rawhide - Single package updates = | ||
== Summary == | == Summary == | ||
We want to gate packages on test results before they can land in rawhide. This will reduce the amount of broken dependency, uninstallable packages and broken composes leading to a more stable rawhide as well as less work on the infrastructure and rel-eng teams to keep composes working. | We want to gate packages on test results before they can land in rawhide. This will reduce the amount of broken dependency, uninstallable packages and broken composes leading to a more stable rawhide as well as less work on the infrastructure and rel-eng teams to keep composes working. | ||
This project will be split in two phases, at first only single package updates will be supported, in a second stage, we will add support for multi-packages updates. | |||
This proposal is about the phase 1 of this project. | |||
== Owner == | == Owner == | ||
Line 15: | Line 19: | ||
* Coordinator: [[User:pingou|Pierre-Yves Chibon]] | * Coordinator: [[User:pingou|Pierre-Yves Chibon]] | ||
* Bodhi: [[User:bowlofeggs|Randy Barlow]] and [[User:abompard|Aurélien Bompard]] | * Bodhi: [[User:bowlofeggs|Randy Barlow]] and [[User:abompard|Aurélien Bompard]] | ||
* Fedora CI: [[User:dperpeet|Dominik Perpeet]] | * Fedora CI: [[User:dperpeet|Dominik Perpeet]] | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | ||
Line 33: | Line 35: | ||
ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA) | ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA) | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
* Tracker bug: <will be assigned by the Wrangler> | |||
--> | --> | ||
== Detailed Description == | == Detailed Description == | ||
At first we want to build the system allowing to gating rawhide, packagers will opt-in into gating [https://docs.pagure.org/greenwave/package-specific-policies.html using greenwave's opt-in gating mechanism] as they want. Once the | Querying the Bodhi database, it was revealed that 95% of all our updates involve a single package. | ||
To be exhaustive, here are the exact number found: | |||
Of all time: | |||
Single build updates: 123,657 (94.1%) | |||
Multi build updates: 7,766 ( 5.9%) | |||
Total: 131,423 | |||
Per release: | |||
Fedora 29: | |||
Single: 4,675 (93.7%) | |||
Multi: 316 ( 6.3%) | |||
Fedora 28: | |||
Single: 9,153 (94.5%) | |||
Multi: 536 ( 5.5%) | |||
EPEL 7: | |||
Single: 12,664 (94.0%) | |||
Multi: 814 ( 6.0%) | |||
When considering gating rawhide package updates on test results, we need to consider two workflows: single package updates, multi-package updates. This proposal only considers the single package updates workflow. [ Another proposal] will be submitted in the future to support the multi package updates workflow. | |||
At first we want to build the system allowing to gating rawhide, packagers will ''opt-in into gating'' [https://docs.pagure.org/greenwave/package-specific-policies.html using greenwave's opt-in gating mechanism] as they want. We will also offer a way to ''opt-out'' so packages depending on other packages can still be built without issues. | |||
We do not aim at making any tests mandatory as part of these proposals. Once the two proposals have been deployed it will be up to the community and likely FESCo to decide if they would like to enforce some rules on all packages and which ones. | |||
=== Workflows === | === Workflows === | ||
Line 46: | Line 80: | ||
<gallery> | <gallery> | ||
Single_package_GatingRawhide_bodhi.png|Single package update with gating | Single_package_GatingRawhide_bodhi.png|Single package update with gating | ||
</gallery> | </gallery> | ||
Line 56: | Line 89: | ||
== Scope == | == 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 scope of this work is adding a mechanism to gate single package updates 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, the tests and the decision on which tests are used to gate upon are out of scope for the present document.''' | '''The CI system, the tests and the decision on which tests are used to gate upon are out of scope for the present document.''' | ||
Line 65: | Line 98: | ||
* Other developers: | * Other developers: | ||
** Bodhi developers: Implement the needed changes | ** Bodhi developers: Implement the needed changes | ||
** infrastructure: deploy the new version of bodhi and the new koji plugin | ** infrastructure: deploy the new version of bodhi and the new koji plugin | ||
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) | * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) | ||
* Policies and guidelines: Once the system is in place, FESCo may want to set a policy on distribution-wide gating (ie: tests that would be enforced for all packages in the distributions). This is however out of scope of this proposal. | * Policies and guidelines: Once the entire system is in place, FESCo may want to set a policy on distribution-wide gating (ie: tests that would be enforced for all packages in the distributions). This is however out of scope of this proposal. | ||
* Trademark approval: N/A (not needed for this Change) | * Trademark approval: N/A (not needed for this Change) | ||
Line 80: | Line 111: | ||
** 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 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). | ** 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). | ||
* Bodhi will comment on the updates when greenwave's decision about an update is known | * Bodhi will comment on the updates when greenwave's decision about an update is known | ||
** This will notify users about the test results and the corresponding gating status. | ** This will notify users about the test results and the corresponding gating status. | ||
==== Greenwave / WaiverDB ==== | ==== Greenwave / WaiverDB ==== | ||
Line 102: | Line 121: | ||
==== CI system ==== | ==== 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. | Nothing should change for the CI system but we will have to confirm this and test in staging that they behave as expected. | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
Line 118: | Line 134: | ||
# Check that the tests have properly ran (see the Tests tab in the bodhi update) | # Check that the tests have properly ran (see the Tests tab in the bodhi update) | ||
# Ensure that the bodhi update went through to rawhide once the tests passed | # Ensure that the bodhi update went through to rawhide once the tests passed | ||
== User Experience == | == User Experience == | ||
Line 143: | Line 149: | ||
failed tests if needed. | failed tests if needed. | ||
=== Multi package update === | === Multi package update with single package update gating === | ||
fedpkg clone rpms/foobar | fedpkg clone rpms/foobar | ||
cd foobar/ | cd foobar/ | ||
vim foobar.spec | vim foobar.spec | ||
git commit -am "Update of foobar to update foo to 1.2" | git commit -am "Update of foobar to update foo to 1.2" | ||
fedpkg push | fedpkg push | ||
fedpkg build --target= | fedpkg build --target=rawhide-candidate | ||
cd .. | cd .. | ||
fedpkg clone rpms/foobaz | fedpkg clone rpms/foobaz | ||
Line 158: | Line 163: | ||
git commit -am "Update of foobaz to update foo to 1.2" | git commit -am "Update of foobaz to update foo to 1.2" | ||
fedpkg push | fedpkg push | ||
fedpkg build --target= | fedpkg build --target=rawhide-candidate | ||
cd .. | cd .. | ||
fedpkg clone rpms/foo | fedpkg clone rpms/foo | ||
Line 165: | Line 170: | ||
git commit -am "Update foo to 1.2" | git commit -am "Update foo to 1.2" | ||
fedpkg push | fedpkg push | ||
fedpkg build --target= | fedpkg build --target=rawhide-candidate | ||
Users are practically by-passing the gating process by specifying a specific build target. | |||
Line 178: | Line 180: | ||
** bus listener to automatically create updates when a build happens in rawhide | ** bus listener to automatically create updates when a build happens in rawhide | ||
** bus listener to automatically push updates who passed gating according to greenwave | ** bus listener to automatically push updates who passed gating according to greenwave | ||
** comment on updates about gating status change/announce to notify packagers about it | ** comment on updates about gating status change/announce to notify packagers about it | ||
== Contingency Plan == | == Contingency Plan == |
Revision as of 11:07, 28 February 2019
Gating Rawhide - Single package updates
Summary
We want to gate packages on test results before they can land in rawhide. This will reduce the amount of broken dependency, uninstallable packages and broken composes leading to a more stable rawhide as well as less work on the infrastructure and rel-eng teams to keep composes working.
This project will be split in two phases, at first only single package updates will be supported, in a second stage, we will add support for multi-packages updates.
This proposal is about the phase 1 of this project.
Owner
- Name: Pierre-Yves Chibon
- Email: pingou - pingoured.fr
People who are/will be involved in this:
- Coordinator: Pierre-Yves Chibon
- Bodhi: Randy Barlow and Aurélien Bompard
- Fedora CI: Dominik Perpeet
- Release notes owner:
Current status
- Targeted release: N/A
- Last updated: 2019-02-28
Detailed Description
Querying the Bodhi database, it was revealed that 95% of all our updates involve a single package.
To be exhaustive, here are the exact number found:
Of all time:
Single build updates: 123,657 (94.1%) Multi build updates: 7,766 ( 5.9%)
Total: 131,423
Per release:
Fedora 29:
Single: 4,675 (93.7%) Multi: 316 ( 6.3%)
Fedora 28:
Single: 9,153 (94.5%) Multi: 536 ( 5.5%)
EPEL 7:
Single: 12,664 (94.0%) Multi: 814 ( 6.0%)
When considering gating rawhide package updates on test results, we need to consider two workflows: single package updates, multi-package updates. This proposal only considers the single package updates workflow. [ Another proposal] will be submitted in the future to support the multi package updates workflow.
At first we want to build the system allowing to gating rawhide, packagers will opt-in into gating using greenwave's opt-in gating mechanism as they want. We will also offer a way to opt-out so packages depending on other packages can still be built without issues.
We do not aim at making any tests mandatory as part of these proposals. Once the two proposals have been deployed it will be up to the community and likely FESCo to decide if they would like to enforce some rules on all packages and which ones.
Workflows
-
Single package update with gating
Benefit to Fedora
- 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
Scope
The scope of this work is adding a mechanism to gate single package updates 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, the tests and the decision on which tests are used to gate upon are out of scope for the present document.
- Proposal owners: pingou will be coordinating the work among the different stack holder
- Other developers:
- Bodhi developers: Implement the needed changes
- infrastructure: deploy the new version of bodhi and the new koji plugin
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- Policies and guidelines: Once the entire system is in place, FESCo may want to set a policy on distribution-wide gating (ie: tests that would be enforced for all packages in the distributions). This is however out of scope of this proposal.
- Trademark approval: N/A (not needed for this Change)
Application impacted
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).
- Bodhi will comment on the updates when greenwave's decision about an update is known
- This will notify users about the test results and the corresponding gating status.
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.
Upgrade/compatibility impact
N/A
How To Test
Single package update
- Add tests to a package you maintain in Fedora using the CI/Quick_Start_Guide documentation (see the full CI documentation for more information).
- Update your package in rawhide
- Ensure that the bodhi update is automatically created
- Check that the tests have properly ran (see the Tests tab in the bodhi update)
- Ensure that the bodhi update went through to rawhide once the tests passed
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 with single package update gating
fedpkg clone rpms/foobar cd foobar/ vim foobar.spec git commit -am "Update of foobar to update foo to 1.2" fedpkg push fedpkg build --target=rawhide-candidate 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=rawhide-candidate cd .. fedpkg clone rpms/foo cd foo vim foo.spec git commit -am "Update foo to 1.2" fedpkg push fedpkg build --target=rawhide-candidate
Users are practically by-passing the gating process by specifying a specific build target.
Dependencies
- Bodhi
- bus listener to automatically create updates when a build happens in rawhide
- bus listener to automatically push updates who passed gating according to greenwave
- comment on updates about gating status change/announce to notify packagers about it
Contingency Plan
We can keep doing rawhide as we are doing it today.
Documentation
To be written/updated
List of documentation pages to update:
- https://fedoraproject.org/wiki/Updates_Policy
- https://fedoraproject.org/wiki/Package_maintenance_guide
- https://fedoraproject.org/wiki/Package_update_HOWTO
- https://docs.fedoraproject.org/en-US/packaging-guidelines/