Gating
Enable Gating
Gating of packages based on test results is currently enabled on demand. If you want to turn the gating on for your component create a new file gating.yaml
in the root of the package dist git directory with the following content:
Enable gate to the testing repository:
--- !Policy product_versions: - fedora-* decision_contexts: [bodhi_update_push_testing] subject_type: koji_build rules: - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
Enable gate to the stable repository (use this one for gating rawhide):
--- !Policy product_versions: - fedora-* decision_contexts: [bodhi_update_push_stable] subject_type: koji_build rules: - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
In order to enable both gates, simply concatenate both examples above. |
To add another test just extend the rules list with additional !PassingTestCaseRule .
|
This will enable gating for all Fedora releases based on the result of the CI Pipeline. A decision context identifies set of policies used for a specific gating. For example, bodhi_update_push_stable
decision context is used for gating RPM builds in Bodhi updates before getting to the stable repository.
The decision_contexts
should match in both remote rules file and the policy in the Greenwave configuration (at least one decision context). Rules define resultsdb test cases that should be considered for the gating decision, in this case fedora-ci.koji-build.tier0.functional
which are tests that were run in the CI based on the tmt or STI configuration in package’s dist-git. If no tests are required for the particular decision context(s) rules should be set to an empty list, i. e. rules: []
, otherwise Greenwave will return, that it could not find any applicable policies.
The following Fedora CI tests can be enabled for gating:
-
fedora-ci.koji-build.tier0.functional - component-specific tests enabled using tmt or STI in dist-git
-
fedora-ci.koji-build.rpmdeplint.functional - to make sure the update’s dependencies are available
-
fedora-ci.koji-build.rpminspect.static-analysis - to check package sanity including ABI stability
-
fedora-ci.koji-build.installability.functional - to make sure package installation / update works well
See Greenwave’s Package-specific policies for more technical details about setting the policy.
Using Multiple Plans
If you are using multiple tmt plans it is also possible to enable gating for selected plans only. Instead of the generic tier0
type use the name of the desired plan in the resultsdb testcase name:
!PassingTestCaseRule {test_case_name: fedora-ci.koji-build.<plan-name>.functional}
For example, rule used to enable gating for the /plans/basic
plan would look like this:
!PassingTestCaseRule {test_case_name: fedora-ci.koji-build./plans/basic.functional}
Before the above-mentioned rules can be used, separate plan reporting has to be enabled. See the Multiple Plans section for details.
Waive
If the failed test result is irrelevant you can waive it using the Bodhi web interface or directly from the command line:
# List blocking test results bodhi updates waive <id> --show
# Specify which tests to waive via: bodhi updates waive <id> --test="dist.rpmlint" --test="atomic-ci" "Comment explaining the waiver"
# Waive all tests: bodhi updates waive <id> --test=all "Comment explaining the waiver"
While the web UI only allows to waive all tests, command line provides a way to select tests which should be waived.
Links
-
Greenwave … service to evaluate gating policies based on test results
-
ResultsDB … results store engine
-
WaiverDB … service for recording waivers against test results
-
Greenwave’s Package-specific policies
-
Implement the possibility to waive missing requirements via bodhi-cli
Want to help? Learn how to contribute to Fedora Docs ›