Packit is an open source project aiming to ease your project's integration with Fedora Linux, CentOS Stream, and other distributions. Packit is mostly used by projects that build RPM packages. We won't go through the onboarding process that was already described in a previous article, but we would like to introduce you to new features that were recently promoted into production.
Testing Farm execution
From Packit, you can easily trigger the tests on Testing Farm even without building the RPMs. This is very handy for projects that basically don't build RPMs but want to use these two services for verifying the code. As a good example, we can refer to the Strimzi project where users consume container images.
In such cases, the users want to trigger the tests, verify the code and see some output. This option is available from the beginning. Users can easily define when to execute the tests for every pull request, commit, or release. That sounds pretty cool; however, when you have complex tests (5+ hours per test run) as we have in Strimzi, you probably don't want to trigger all tests for each commit. So, how can the users achieve that?
Manual trigger
We introduced a new configuration option manual_trigger to enable triggering Packit jobs only manually. With this new configuration of Packit jobs, users can easily enable the manual trigger of a job, and this job is not automatically triggered when, for example, a new commit arrives to pull a request.
Users just need to specify manual_trigger in the test's job description. Only boolean values are allowed with the default configuration set to False. Examples of manual trigger configurations can be found in the YAML file.
...
- job: tests
trigger: pull_request
identifier: "regression-operators"
targets:
- centos-stream-9-x86_64
- centos-stream-9-aarch64
skip_build: true
manual_trigger: true
labels:
- regression
- operators
- regression-operators
- ro
tf_extra_params:
test:
fmf:
name: regression-operators
...
This new configuration allows users to onboard a new flow when a pull request is opened. For example, in draft mode, users push new commits and fixes, and when they are about to finish the pull request, they can easily type /packit test as a pull request comment, and all jobs defined in packit.yaml for the pull request are triggered.
Labeling and identifying
The solution just described is very easy to use; however, there might be use cases where the users don't want to trigger all the jobs. For example, when you have 10 jobs defined with different test scopes, you probably don't want to trigger acceptance and regression tests at the same time as acceptance could be a subset of regression.
Users now have two options for triggering a specific job. The first one is to trigger the job based on the identifier. When the user specifies identifier: test-1 in the job configuration, the Packit comment command for execution of the tests will look like this /packit test –identifier test1. That command will execute jobs with this specific identifier, nothing else (Figure 1).
What if we want to execute more than one job? Users can use multiple identifiers in a comma-separated list, but it might be a little bit annoying to specify long identifiers every time. To add a better user experience, we've introduced labels configuration that could group together multiple jobs. Command /packit test –labels upgrade,regression will trigger all jobs that contain upgrade or regression in the list of labels in the job configuration.
Conclusion
If you hesitated with onboarding to Packit due to the limitation of missing manual triggering of the jobs and missing labeling, you can start with onboarding now! As we already mentioned, Packit is an open source service and these improvements were done as contributions from outside of the Packit team. Everyone can contribute, so if you are missing some features, feel free to open a pull request.
To see more information about newly added options, check out the documentation. If you are new to Packit, you can also watch talks from the Packit team from DevConf 2023 and DevConf Mini 2023.
