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

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.


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.