{"id":134194,"date":"2023-07-17T08:00:00","date_gmt":"2023-07-17T08:00:00","guid":{"rendered":"https:\/\/fedoramagazine.org\/?p=38524"},"modified":"2023-07-17T08:00:00","modified_gmt":"2023-07-17T08:00:00","slug":"packit-how-to-trigger-jobs-manually","status":"publish","type":"post","link":"https:\/\/sickgaming.net\/blog\/2023\/07\/17\/packit-how-to-trigger-jobs-manually\/","title":{"rendered":"Packit \u2013 how to trigger jobs manually"},"content":{"rendered":"<p>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 <a href=\"https:\/\/developers.redhat.com\/articles\/2022\/08\/16\/how-set-packit-simplify-upstream-project-integration#\" target=\"_blank\" rel=\"noreferrer noopener\">here<\/a>. <\/p>\n<p> <span id=\"more-38524\"><\/span> <\/p>\n<h2 class=\"wp-block-heading\">Testing Farm execution<\/h2>\n<p>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 <a href=\"https:\/\/strimzi.io\/\" target=\"_blank\" rel=\"noreferrer noopener\"><u>Strimzi project<\/u><\/a> where users consume container images.<\/p>\n<p>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 &#8211; 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\u2019t want to trigger all tests for each commit. So how can the users achieve that?<\/p>\n<h3 class=\"wp-block-heading\">Manual Trigger<\/h3>\n<p>We introduced a new configuration option,&nbsp;<kbd>manual_trigger<\/kbd>, 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.<\/p>\n<p>Users need to specify <kbd>manual_trigger<\/kbd> in the test&#8217;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 <a href=\"https:\/\/github.com\/strimzi\/strimzi-kafka-operator\/blob\/main\/.packit.yaml\" target=\"_blank\" rel=\"noreferrer noopener\"><u>here<\/u><\/a>.<\/p>\n<pre class=\"wp-block-preformatted\">... - 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\n...\n<\/pre>\n<p>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 <kbd>\/packit test<\/kbd> as a pull request comment and all jobs defined in packit.yaml for pull request will be triggered.<\/p>\n<h3 class=\"wp-block-heading\">Labeling and identifying<\/h3>\n<p>The above solution is very easy to use. There might be use cases, however, where users don\u2019t want to trigger all the jobs. For example, when you have 10 jobs defined with different test scopes, you probably don\u2019t want to trigger acceptance and regression tests at the same time since acceptance could be a subset of regression.<\/p>\n<p>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 <kbd>identifier: test-1<\/kbd> in the job configuration, Packit comment command for execution of the tests will look like this<kbd> \/packit test \u2013identifier test1<\/kbd>. This command will execute jobs with the specific identifier (<kbd>test-1<\/kbd>) and nothing else. <\/p>\n<figure class=\"wp-block-image is-style-default\"><a href=\"https:\/\/www.sickgaming.net\/blog\/wp-content\/uploads\/2023\/08\/packit-how-to-trigger-jobs-manually.png\"><img decoding=\"async\" loading=\"lazy\" width=\"997\" height=\"840\" src=\"https:\/\/www.sickgaming.net\/blog\/wp-content\/uploads\/2023\/08\/packit-how-to-trigger-jobs-manually.png\" alt=\"An example how to trigger testing-farm test job via Packit with --identifier parameter.\" class=\"wp-image-38525\" title=\"Trigger packit job with --identifier\" \/><\/a><\/figure>\n<p>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&#8217;ve introduced the <kbd>labels<\/kbd> configuration that allows grouping together multiple jobs. The command <kbd>\/packit test \u2013labels upgrade,regression<\/kbd> will trigger all jobs that contain <kbd>upgrade<\/kbd> or <kbd>regression<\/kbd> in the list of labels in the job configuration. <\/p>\n<figure class=\"wp-block-image\"><a href=\"https:\/\/www.sickgaming.net\/blog\/wp-content\/uploads\/2023\/08\/packit-how-to-trigger-jobs-manually-1.png\"><img decoding=\"async\" loading=\"lazy\" width=\"997\" height=\"840\" src=\"https:\/\/www.sickgaming.net\/blog\/wp-content\/uploads\/2023\/08\/packit-how-to-trigger-jobs-manually-1.png\" alt=\"An example how to trigger testing-farm test job via Packit with --labels parameter.\" class=\"wp-image-38526\" title=\"Trigger packit job with --labels\" \/><\/a><\/figure>\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n<p>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 <a href=\"https:\/\/devconfcz2023.sched.com\/event\/1MYme\/become-an-open-source-service?linkback=grid\" target=\"_blank\" rel=\"noreferrer noopener\"><u>open-source service<\/u><\/a> 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!<\/p>\n<p>For more information about newly added options you should check the <a href=\"https:\/\/packit.dev\/docs\/testing-farm\/\" target=\"_blank\" rel=\"noreferrer noopener\"><u>documentation<\/u><\/a>. In case you are new to Packit you can also view the talk from the Packit team from <a href=\"https:\/\/devconfcz2023.sched.com\/event\/1MYlL\/packit-rpm-integration-all-in-one?linkback=grid\" target=\"_blank\" rel=\"noreferrer noopener\"><u>DevConf 2023<\/u><\/a> or <a href=\"https:\/\/www.youtube.com\/watch?v=e2aCilMy-5U\" target=\"_blank\" rel=\"noreferrer noopener\"><u>DevConf Mini 2023<\/u><\/a>. \u200b<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":134195,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[48],"tags":[45,61,46,47],"class_list":["post-134194","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-fedora-os","tag-fedora","tag-fedora-project-community","tag-magazine","tag-news"],"_links":{"self":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/134194","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/comments?post=134194"}],"version-history":[{"count":0,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/posts\/134194\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media\/134195"}],"wp:attachment":[{"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/media?parent=134194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/categories?post=134194"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sickgaming.net\/blog\/wp-json\/wp\/v2\/tags?post=134194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}