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?
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
regression in the list of labels in the job configuration.
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.