index.md

title	date	authors	tags
(Tests) job triggering improvements	2023-07-11 08:46:18 +0200	lbarczio	configuration

Recently, we received multiple contributions from the Strimzi team, specifically Jakub Stejskal and David Kornel, for the functionality of manual triggering of jobs and other related improvements, mostly focusing on the testing UX. We are very happy about these and would like to showcase the results of their awesome contributions.

Strimzi team wanted to onboard Packit to ease their testing in pull requests, but they have had multiple test suites that could run for a long time, and they did not want to run all of the test suites for each new commit in a pull request.

Let's now look together at what they implemented to solve their usecase.

Manual-only triggering of jobs

Firstly, a new configuration option manual_trigger was introduced. With this new configuration option, users can enable triggering Packit jobs only manually and avoid specified jobs being automatically triggered when, e.g., a new commit arrives to a pull request. The only thing needed to make this work is to add manual_trigger: true to the job's definition:

- job: tests
  trigger: pull_request
  targets:
    - centos-stream-9-x86_64
  skip_build: true
  manual_trigger: true

This new configuration option allows saving resources and running builds or tests, e.g. only when the pull request is ready for testing and can be especially useful for projects having huge test plans.

Triggering test jobs based on labels and identifiers

The above solution is very easy to use; however, there might be use cases where the users don’t want to trigger all the jobs. A particular example could be running a smoke test job before running the sanity one.

To solve this, for the test jobs, Jakub and David introduced 2 new ways to trigger a specific job.

The first one is to trigger the job based on the configured identifier. To trigger a test job with identifier: regression-operators in the job configuration, the Packit comment command will be:

/packit test --identifier regression-operators

That command will execute the job with this specific identifier, nothing else.

And what if someone wants to execute more than one job? Users can easily use multiple identifiers in a comma-separated list:

/packit test --identifier regression-operators,regression-components

But specifying a longer list of identifiers every time might get a little bit annoying, especially when the identifiers are usually used together repeatedly.

To improve the UX, there was introduced labels configuration field that can group together multiple jobs. Each job can contain a list of labels in their definition:

- job: tests
  trigger: pull_request
  identifier: regression-operators
  targets:
    - centos-stream-9-x86_64
  skip_build: true
  manual_trigger: true
  labels:
    - regression
    - sanity

- job: tests
  trigger: pull_request
  identifier: regression-components
  targets:
    - centos-stream-9-x86_64
  skip_build: true
  manual_trigger: true
  labels:
    - regression

- job: tests
  trigger: pull_request
  identifier: acceptance-operators
  targets:
    - centos-stream-9-x86_64
  skip_build: true
  manual_trigger: true
  labels:
    - acceptance
    - sanity

With this, one can comment

/packit test --labels regression

and the comment will trigger all jobs that contain regression in the list of labels in the job configuration. It is again also possible to specify a comma-separated list of labels:

/packit test --labels regression,sanity

Conclusion

As already mentioned, these improvements were made as contributions from outside of the Packit team, and it was such a nice experience to collaborate with someone new! And this brings us to a reminder: Anyone can contribute! So if you are missing some features, feel free to open a pull request, and we will gladly help you so that your feature can land in our production!