How to Opt in to Gating?

There are two steps to do in order to opt in to Rawhide Gating:

  • Add tests to your package.

  • Configure gating, so that your package is gated on those tests.

Add Tests to Your Package

You can add tests by following the documentation on how to write tests.

The gist of it is: Add a tests/ folder in the git repository of your package and place a file called tests.yml in it. This file should be an Ansible playbook with all the steps required to test your package.

You need to “tag” the playbook with any or all of the following tags so the tests can be called in the different environments: classic, container, atomic.

Once you have added a tests/tests.yml file, for every update that is subsequently created for that package, the tests will be run and will be shown in the update page under the test results tab.

For these tests to have an effect, you need to configure the system to gate on them.

Configure Gating

To configure the system to gate your package on tests, you need to add a file called gating.yaml to the git repository of the package(s) you want gated.

A simple example for gating.yaml would look like this:

--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_testing
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_stable
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}

Basically, it contains two policies, one to push a build to testing and one to push a build to stable and for both of these situations, it asks that the test named org.centos.prod.ci.pipeline.allpackages-build.complete passes.

For gating rawhide itself, you only need the decision_context: bodhi_update_push_stable, while for stable branches, you will need both.

If gating on your package-level tests is all you are interested in, you can use this example as is.

If you are also interested in some of the Taskotron checks, such as dist.python-versions or dist.python-versions.py3_support, you could amend the file so it looks like:

--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_testing
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
  - !PassingTestCaseRule {test_case_name: dist.python-versions}
  - !PassingTestCaseRule {test_case_name: dist.python-versions.py3_support}
--- !Policy
product_versions:
  - fedora-*
decision_context: bodhi_update_push_stable
subject_type: koji_build
rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
  - !PassingTestCaseRule {test_case_name: dist.python-versions}
  - !PassingTestCaseRule {test_case_name: dist.python-versions.py3_support}

You can find more about this file in Greenwave’s documentation about package specific policies.

Want to help? Learn how to contribute to Fedora Docs ›