Gating

Distro-wide Required Gating

The Fedora greenwave configuration enforces some distribution-wide gating policies. Updates in most critical path groups (not the ones for non-release-blocking desktops) are gated on subsets of the Fedora openQA update test suite depending on which group(s) they are in. This gating is not optional and cannot be disabled.

Optional Gating

Additional gating requirements can be enabled on demand on a package-by-package basis. If you want to turn the gating on for your package, 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:

--- !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 Jenkins pipeline that runs the package’s TMT tests. 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. Note that Bodhi’s handling of these two decision contexts is buggy. Updates are never in fact prevented from push to testing even if there is a bodhi_update_push_testing policy and it fails. But it is best to include both contexts in your policy with identical requirements, or else the reported "gating status" of your update in the Bodhi web UI may change in confusing ways with strange effects, as described in the bug report.

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 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:

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. However, please do not waive Fedora openQA failures - test cases whose name starts with update. If you waive an openQA failure, the same failure will likely be "inherited" in every subsequent test of any other update, and cause all other updates to be gated. Please contact the Fedora Quality team for help resolving failed openQA tests instead. Command line waive examples:

# 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.