Packit is an open-source project aiming to ease the integration of your project with Fedora Linux, CentOS Stream, and other distributions. Projects that use Packit usually build RPM packages. This article will introduce new features. The new user onboarding process is available here.
Testing Farm execution
From Packit you can easily trigger your tests on Testing Farm without building the RPMs. This is very handy for projects that basically may not build RPMs, but just want to use these two services for verifying the code. As a good example, we refer to the Strimzi project where users consume container images.
In such cases, the users just want to trigger the tests, verify the code and see some output. This option is available from the beginning. Users can easily define when the tests will be executed – for every pull request, for every commit, or for releases. That sounds pretty cool. However, when you have complex tests (5h+ 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 triggering of a job. The job will NOT automatically trigger when, for example, a new commit arrives to pull a request.
Users need to specify manual_trigger in the test’s job description. The value for this option must be boolean and will default to False. The following is an example of the use of this option. A more complete example is available here.
... - 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 option allows users to utilize a new flow. When a pull request is opened (for example in draft mode), users push new commits and fixes, or 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 pull request will be triggered.
Labeling and identifying
The above solution is very easy to use. There might be use cases, however, where 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 since acceptance could be a subset of regression.
There are now two options to trigger a specific job. The first one is to trigger the job based on an identifier. If the user specifies identifier: test-1 in the job configuration, Packit comment command for execution of the tests will look like this /packit test –identifier test1. This command will execute jobs with the specific identifier (test-1) and nothing else.
The second option for triggering specific jobs allows you to execute more than one job based on their identifiers. You can use multiple identifiers in a comma-separated list but it might be cumbersome to specify long lists of identifiers every time. To add a better user experience we’ve introduced the labels configuration that allows grouping together multiple jobs. The 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 to utilize Packit due to the limitation of missing manual triggering of the jobs or missing labeling, you can start now! As 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!
For more information about newly added options you should check the documentation. In case you are new to Packit you can also view the talk from the Packit team from DevConf 2023 or DevConf Mini 2023. ?
Jakub Stejskal
Experienced Quality Engineer with a demonstrated history of working in the computer software industry. Skilled in Test Automation, Apache Kafka, Jenkins, and Java. Interested in CI/CD tools and one of the Strimzi project maintainers.
David Kornel
Principal software quality engineer working in Red Hat. Focusing on kubernetes/openshift, testing kubernetes operators and automating testing process with Jenkins pipelines, tekton and ArgoCD.
