From 6b84b86e056843bf4e2688398b7240156a891993 Mon Sep 17 00:00:00 2001 From: Laura Barcziova Date: Tue, 15 Apr 2025 14:00:58 +0200 Subject: [PATCH 1/3] Create separate page for retriggering docs Fixes #1027 --- docs/configuration/index.md | 2 +- .../dist-git-onboarding.md | 36 +---- docs/guide.md | 110 +------------- docs/index.md | 1 + docs/retriggering.md | 142 ++++++++++++++++++ 5 files changed, 148 insertions(+), 143 deletions(-) create mode 100644 docs/retriggering.md diff --git a/docs/configuration/index.md b/docs/configuration/index.md index 1be0835d92..288dd651ed 100644 --- a/docs/configuration/index.md +++ b/docs/configuration/index.md @@ -1,6 +1,6 @@ --- title: Configuration -sidebar_position: 7 +sidebar_position: 6 --- # Configuration diff --git a/docs/fedora-releases-guide/dist-git-onboarding.md b/docs/fedora-releases-guide/dist-git-onboarding.md index a12fc44863..73c19d9177 100644 --- a/docs/fedora-releases-guide/dist-git-onboarding.md +++ b/docs/fedora-releases-guide/dist-git-onboarding.md @@ -236,39 +236,7 @@ open issues in case of errors during the downstream jobs via [`issue_repository` configuration key. See the details in the link. ## Retriggering -### pull_from_upstream -Packagers can retrigger the job -via a comment in any dist-git pull request: - - /packit pull-from-upstream - -This will take the Packit configuration file from the default branch of the dist-git - repository (`rawhide`), same as if the job was triggered by a new release. To use the configuration file from the dist-git pull request you are commenting on, you can add an argument: - - /packit pull-from-upstream --with-pr-config - -### koji_build - -Packagers can retrigger a build by a comment in a dist-git pull request: - - /packit koji-build - -The build will be triggered for the target branch of the pull request using the most recent commit on the target branch -(NOT the HEAD commit of the pull request). - -If Packit created an issue in the configured `issue_repository`, you can place the same comment in that -issue to retrigger the builds (see [`issue_repository`](/docs/configuration#issue_repository) for details). - -### bodhi_update -Packagers with write access to the dist-git repository can retrigger an update by a comment in a dist-git pull request: - - /packit create-update - -The update will be triggered for the target branch of the pull request. - -If Packit created an issue in the configured `issue_repository`, you can place the same comment in that -issue to retrigger the updates (see [`issue_repository`](/docs/configuration#issue_repository) for details). - +You can find all the information on retriggering [here](../retriggering.md). ## Full example of a dist-git only configuration @@ -293,4 +261,4 @@ jobs: trigger: commit dist_git_branches: - fedora-branched # rawhide updates are created automatically -``` +``` \ No newline at end of file diff --git a/docs/guide.md b/docs/guide.md index 8f6b9533a0..8bf47e000f 100644 --- a/docs/guide.md +++ b/docs/guide.md @@ -453,113 +453,7 @@ An example of Packit's checks in a pull request: ![Packit pull request](img/guide/guide_pr_status.png) ## Retriggering -### Comments for upstream jobs - -In general, you can put a `/packit ` comment -to trigger the Packit job manually. - -#### copr_build -So for [Copr builds](/docs/configuration/upstream/copr_build), Packit is able to trigger new builds based on a pull request comment: - - /packit copr-build - -or the shorter version - - /packit build - -So whenever you run into a flake or feel like you want to retrigger, just type -that comment into the PR and enjoy some fine, fresh builds. - -It is also possible to re-trigger only the failed builds using a pull request comment - - /packit rebuild-failed - -The same can be used to retrigger jobs configured with either `commit` or `release` -trigger by specifying the respective arguments, using commit comments: - - /packit build --commit - -or - - /packit build --release - -If no additional arguments are provided, Packit defaults to the commit trigger on the repository's -default branch. The job will execute only if a corresponding job configuration exists for the -specified branch or release and if the commit is included on the specified branch or tag. - -#### propose_downstream -For [`propose_downstream`](/docs/configuration/upstream/propose_downstream), you need to place this comment to any issue: - - /packit propose-downstream - - -#### tests - -For retriggering the [`tests`](/docs/configuration/upstream/tests) jobs, you can use a pull-request comment: - - /packit test - - -And to re-trigger only the failed tests, you can use - - /packit retest-failed - -For testing, there is possible to specify also other arguments for more advanced use-cases, see -the details [here](/docs/configuration/upstream/tests#running-tests-with-builds-from-another-pull-request). - -The same can be used to retrigger jobs configured with either `commit` or `release` -trigger by specifying the respective arguments, using commit comments: - - /packit test --commit - -or - - /packit test --release - -If no additional arguments are provided, Packit defaults to the commit trigger on the repository's -default branch. The job will execute only if a corresponding job configuration exists for the -specified branch or release and if the commit is included on the specified branch or tag. - -#### upstream_koji_build - -For retriggering the [`upstream_koji_build`](/docs/configuration/upstream/upstream_koji_build) jobs, you can -again use a pull-request comment: - - /packit upstream-koji-build - -#### vm_image_build - -[VM Image builds](/docs/configuration/upstream/vm_image_build) are not triggered automatically at all. -To trigger them, you need to post a pull-request comment: - - /packit vm-image-build - -every time. - - -:::caution - -The requirements stated [above](#approval) apply, so if you see this message - - Only users with write or admin permissions to the repository can trigger - Packit-as-a-Service - -it means the author of the comment does not have write access to the -repository so the build cannot be scheduled. This is a perfect case for -maintainers of the repository to post `/packit build` in the PR to get a build. - -::: - -### GitHub Checks UI -In GitHub Checks interface, it is also possible to re-trigger a specific task just by clicking on `Re-run` -for the particular check: - -![Re-run GitHub check](img/github/github-check-rerun.png) - -The button is available only for users with write permissions to the repository. - -### Comments for downstream jobs -See [Retriggering](./fedora-releases-guide/dist-git-onboarding#retriggering) in Dist-git repository onboarding. +You can find all the information on retriggering [here](./retriggering.md). And that's about it. Now you should be able to use the core features of the Packit. @@ -567,4 +461,4 @@ If you have any questions, feel free to [reach out to us](/#contact). We welcome all kinds of suggestions to this guide, feel free to [open a new issue -here](https://github.com/packit/packit.dev/issues/new). +here](https://github.com/packit/packit.dev/issues/new). \ No newline at end of file diff --git a/docs/index.md b/docs/index.md index 75b68cb8af..b3a448a729 100644 --- a/docs/index.md +++ b/docs/index.md @@ -8,6 +8,7 @@ sidebar_position: 0 * [Onboarding Guide](docs/guide) - How to start using Packit. * [Fedora release guide](docs/fedora-releases-guide) - How to automate Fedora releases with Packit. * [Configuration for Packit](docs/configuration) - Configuration file description. +* [Retriggering](docs/retriggering) - How to retrigger Packit jobs. * [Packit CLI](docs/cli) - Commands description. * [Actions](docs/configuration/actions) - Further customize Packit's behaviour. * [Generated code in upstream archives](docs/archive-not-matching-git) - When your release tarballs contain generated code and you need to patch it downstream. diff --git a/docs/retriggering.md b/docs/retriggering.md new file mode 100644 index 0000000000..5989c8c3e2 --- /dev/null +++ b/docs/retriggering.md @@ -0,0 +1,142 @@ +--- +title: Retriggering +sidebar_position: 7 +--- + +## Comments +In general, you can put a `/packit ` comment +to trigger the Packit job manually. + +### copr_build +So for [Copr builds](/docs/configuration/upstream/copr_build), Packit is able to trigger new builds based on a pull request comment: + + /packit copr-build + +or the shorter version + + /packit build + +So whenever you run into a flake or feel like you want to retrigger, just type +that comment into the PR and enjoy some fine, fresh builds. + +It is also possible to re-trigger only the failed builds using a pull request comment + + /packit rebuild-failed + +The same can be used to retrigger jobs configured with either `commit` or `release` +trigger by specifying the respective arguments, using commit comments: + + /packit build --commit + +or + + /packit build --release + +If no additional arguments are provided, Packit defaults to the commit trigger on the repository's +default branch. The job will execute only if a corresponding job configuration exists for the +specified branch or release and if the commit is included on the specified branch or tag. + +### propose_downstream +For [`propose_downstream`](/docs/configuration/upstream/propose_downstream), you need to place this comment to any issue: + + /packit propose-downstream + + +### tests + +For retriggering the [`tests`](/docs/configuration/upstream/tests) jobs, you can use a pull-request comment: + + /packit test + + +And to re-trigger only the failed tests, you can use + + /packit retest-failed + +For testing, there is possible to specify also other arguments for more advanced use-cases, see +the details [here](/docs/configuration/upstream/tests#running-tests-with-builds-from-another-pull-request). + +The same can be used to retrigger jobs configured with either `commit` or `release` +trigger by specifying the respective arguments, using commit comments: + + /packit test --commit + +or + + /packit test --release + +If no additional arguments are provided, Packit defaults to the commit trigger on the repository's +default branch. The job will execute only if a corresponding job configuration exists for the +specified branch or release and if the commit is included on the specified branch or tag. + +### upstream_koji_build + +For retriggering the [`upstream_koji_build`](/docs/configuration/upstream/upstream_koji_build) jobs, you can +again use a pull-request comment: + + /packit upstream-koji-build + +### vm_image_build + +[VM Image builds](/docs/configuration/upstream/vm_image_build) are not triggered automatically at all. +To trigger them, you need to post a pull-request comment: + + /packit vm-image-build + +every time. + + +:::caution + +The requirements stated [above](#approval) apply, so if you see this message + + Only users with write or admin permissions to the repository can trigger + Packit-as-a-Service + +it means the author of the comment does not have write access to the +repository so the build cannot be scheduled. This is a perfect case for +maintainers of the repository to post `/packit build` in the PR to get a build. + +::: + +### pull_from_upstream +Packagers can retrigger the job +via a comment in any dist-git pull request: + + /packit pull-from-upstream + +This will take the Packit configuration file from the default branch of the dist-git + repository (`rawhide`), same as if the job was triggered by a new release. To use the configuration file from the dist-git pull request you are commenting on, you can add an argument: + + /packit pull-from-upstream --with-pr-config + +### koji_build + +Packagers can retrigger a build by a comment in a dist-git pull request: + + /packit koji-build + +The build will be triggered for the target branch of the pull request using the most recent commit on the target branch +(NOT the HEAD commit of the pull request). + +If Packit created an issue in the configured `issue_repository`, you can place the same comment in that +issue to retrigger the builds (see [`issue_repository`](/docs/configuration#issue_repository) for details). + +### bodhi_update +Packagers with write access to the dist-git repository can retrigger an update by a comment in a dist-git pull request: + + /packit create-update + +The update will be triggered for the target branch of the pull request. + +If Packit created an issue in the configured `issue_repository`, you can place the same comment in that +issue to retrigger the updates (see [`issue_repository`](/docs/configuration#issue_repository) for details). + + +## GitHub Checks UI +In GitHub Checks interface, it is also possible to re-trigger a specific task just by clicking on `Re-run` +for the particular check: + +![Re-run GitHub check](img/github/github-check-rerun.png) + +The button is available only for users with write permissions to the repository. From 897ac65b08c0c118cfe8e73f536956032174b845 Mon Sep 17 00:00:00 2001 From: Laura Barcziova Date: Tue, 15 Apr 2025 16:17:19 +0200 Subject: [PATCH 2/3] Update references to retriggering docs --- docs/configuration/downstream/bodhi_update.md | 2 +- docs/configuration/downstream/koji_build.md | 4 ++-- docs/fedora-releases-guide/what-to-know.md | 2 +- posts/pull-from-upstream/index.md | 2 +- weekly/2023.md | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/configuration/downstream/bodhi_update.md b/docs/configuration/downstream/bodhi_update.md index 2b05343a5c..dfb6dfecff 100644 --- a/docs/configuration/downstream/bodhi_update.md +++ b/docs/configuration/downstream/bodhi_update.md @@ -19,7 +19,7 @@ You can also utilise [Fedora Notifications](https://apps.fedoraproject.org/notifications/about) to tweak the notifications settings. -For retriggering the job, see [our release guide](/docs/fedora-releases-guide/dist-git-onboarding#retriggering). +For retriggering the job, see [retriggering docs](/docs/retriggering#bodhi_update). :::tip Downstream configuration template diff --git a/docs/configuration/downstream/koji_build.md b/docs/configuration/downstream/koji_build.md index b9e5569087..87b8f0818c 100644 --- a/docs/configuration/downstream/koji_build.md +++ b/docs/configuration/downstream/koji_build.md @@ -26,7 +26,7 @@ specified in the `allowed_pr_authors`. Due to a [bug](https://github.com/packit/packit-service/issues/2537), if you merge a PR containing more than one commit or push more than one commit directly, the job may not be triggered even though all conditions are met. -In such case please [trigger it manually](/docs/fedora-releases-guide/dist-git-onboarding#retriggering). +In such case please [trigger it manually](/docs/retriggering#koji_build). ::: @@ -37,7 +37,7 @@ The koji build behaves as it was created manually, and you can utilise to be informed about the builds. Also, you can configure a repository where should we open issues in case of errors during the job via [`issue_repository`](/docs/configuration#issue_repository) configuration key. -For retriggering the job, see [our release guide](/docs/fedora-releases-guide/dist-git-onboarding#retriggering). +For retriggering the job, see [retriggering docs](/docs/retriggering#koji_build). For Koji builds from upstream, see [`upstream_koji_build`](/docs/configuration/upstream/upstream_koji_build). diff --git a/docs/fedora-releases-guide/what-to-know.md b/docs/fedora-releases-guide/what-to-know.md index 4e07073034..22d0fea7a5 100644 --- a/docs/fedora-releases-guide/what-to-know.md +++ b/docs/fedora-releases-guide/what-to-know.md @@ -58,7 +58,7 @@ There is an [open issue](https://github.com/packit/packit-service/issues/2404) f ### Service-based retriggering -Each job configured in `packit.yml` can be retriggered via dist-git pull request comments. See the [complete list of commands](https://packit.dev/docs/fedora-releases-guide/dist-git-onboarding#retriggering). +Each job configured in `packit.yml` can be retriggered via dist-git pull request comments. See the [complete list of commands](https://packit.dev/docs/retriggering). ### Manual CLI Operations diff --git a/posts/pull-from-upstream/index.md b/posts/pull-from-upstream/index.md index 3cd2497a1a..2c3362a2c6 100644 --- a/posts/pull-from-upstream/index.md +++ b/posts/pull-from-upstream/index.md @@ -115,7 +115,7 @@ also notified about errors: :::tip Update July 2023 It is now also possible to retrigger the job, see -[the details](/docs/configuration/downstream/pull_from_upstream#retriggering). +[the details](/docs/retriggering). ::: diff --git a/weekly/2023.md b/weekly/2023.md index 1970d2d1b4..0ab3f8f960 100644 --- a/weekly/2023.md +++ b/weekly/2023.md @@ -139,7 +139,7 @@ Thank you, [@SpyTec](https://github.com/SpyTec) for so many [wonderful changes i We have experienced issues with automatic Bodhi updates that we are investigating. In case you miss a Bodhi update, you can -[retrigger the job](https://packit.dev/docs/fedora-releases-guide/#retriggering-2) via `/packit create-update` +[retrigger the job](https://packit.dev/docs/retriggering#bodhi_update) via `/packit create-update` comment in a dist-git pull request. Besides that, during this short week (another Czech Republic public holiday) we didn't manage to implement any significant new features. From 9efe4256947ae788ff08c9a59493e1be014ec41e Mon Sep 17 00:00:00 2001 From: Laura Barcziova Date: Tue, 15 Apr 2025 16:19:39 +0200 Subject: [PATCH 3/3] Move out job specific retriggering docs and link them We want to have one authoritative page that will have the up to date info so that we don't need to update info on multiple places in case of changes. --- docs/configuration/downstream/bodhi_update.md | 7 +- docs/configuration/downstream/koji_build.md | 6 +- .../downstream/pull_from_upstream.md | 18 +--- docs/configuration/upstream/copr_build.md | 4 + .../upstream/propose_downstream.md | 4 +- docs/configuration/upstream/tests.md | 52 +--------- .../upstream/upstream_koji_build.md | 4 + docs/configuration/upstream/vm_image_build.md | 4 + docs/retriggering.md | 95 ++++++++++++------- 9 files changed, 87 insertions(+), 107 deletions(-) diff --git a/docs/configuration/downstream/bodhi_update.md b/docs/configuration/downstream/bodhi_update.md index dfb6dfecff..2335be0b3b 100644 --- a/docs/configuration/downstream/bodhi_update.md +++ b/docs/configuration/downstream/bodhi_update.md @@ -19,8 +19,6 @@ You can also utilise [Fedora Notifications](https://apps.fedoraproject.org/notifications/about) to tweak the notifications settings. -For retriggering the job, see [retriggering docs](/docs/retriggering#bodhi_update). - :::tip Downstream configuration template You can use our [downstream configuration template](/docs/configuration/downstream_configuration_template) @@ -66,7 +64,10 @@ Packit dist-git configuration. a `koji_build` job with the same sidetag group configured in package `foo` in this update, you need to list `foo` here. - +## Retriggering + +For retriggering the job, see [retriggering docs](/docs/retriggering#bodhi_update). + ## Example ```yaml issue_repository: https://github.com/my-username/packit-notifications diff --git a/docs/configuration/downstream/koji_build.md b/docs/configuration/downstream/koji_build.md index 87b8f0818c..934d1d9c7b 100644 --- a/docs/configuration/downstream/koji_build.md +++ b/docs/configuration/downstream/koji_build.md @@ -37,8 +37,6 @@ The koji build behaves as it was created manually, and you can utilise to be informed about the builds. Also, you can configure a repository where should we open issues in case of errors during the job via [`issue_repository`](/docs/configuration#issue_repository) configuration key. -For retriggering the job, see [retriggering docs](/docs/retriggering#koji_build). - For Koji builds from upstream, see [`upstream_koji_build`](/docs/configuration/upstream/upstream_koji_build). :::tip Downstream configuration template @@ -113,6 +111,9 @@ Packit dist-git configuration. * **require.label** - you can specify labels that have to be present/absent on a pull request in order to trigger the build when it is merged. See configuration details [here](/docs/configuration#require). +## Retriggering + +For retriggering the job, see [retriggering docs](/docs/retriggering#koji_build). ## Processing of dist-git events from Pagure @@ -176,6 +177,7 @@ Because of the potential issues with rendering: - continous lines represent _yes_ ::: + ### Example ```yaml diff --git a/docs/configuration/downstream/pull_from_upstream.md b/docs/configuration/downstream/pull_from_upstream.md index 5af44759e8..9bc2cba211 100644 --- a/docs/configuration/downstream/pull_from_upstream.md +++ b/docs/configuration/downstream/pull_from_upstream.md @@ -92,24 +92,8 @@ For more details and customization options, also check ::: ## Retriggering -Packagers can retrigger the job -via a comment in any dist-git pull request: - /packit pull-from-upstream - -This will take the Packit configuration file from the default branch of the dist-git - repository (`rawhide`), same as if the job was triggered by a new release. -You can monitor the job in [Packit Dashboard](https://dashboard.packit.dev/jobs/pull-from-upstreams). -To use the configuration file from the dist-git pull request you are commenting on, you can add an argument: - - /packit pull-from-upstream --with-pr-config - - -`pull-from-upstream` automatically handles the Bugzilla created by Upstream -Release Monitoring (by default adds `Resolves` to changelog/commit and exposes `PACKIT_RESOLVED_BUGS` to the `changelog-entry` and `commit-message` -actions). If you want to override the referenced resolved bug set by Packit, you can retrigger `pull_from_upstream` like this: - - /packit pull-from-upstream --resolve-bug rhbz#123,rhbz#124 +For retriggering the job, see [retriggering docs](/docs/retriggering#pull_from_upstream). ## Example diff --git a/docs/configuration/upstream/copr_build.md b/docs/configuration/upstream/copr_build.md index cfa0ba14ed..4fb1ba1e0d 100644 --- a/docs/configuration/upstream/copr_build.md +++ b/docs/configuration/upstream/copr_build.md @@ -86,6 +86,10 @@ that can change the behaviour of your Copr builds: * [**release_suffix**](https://packit.dev/docs/configuration#release_suffix) * [**srpm_build_deps**](https://packit.dev/docs/configuration#srpm_build_deps) +## Retriggering + +For retriggering the job, see [retriggering docs](/docs/retriggering#copr_build). + ## Using a custom Copr project When using a custom Copr project (by specifying `project` and `owner`) you need to: - allow Packit to build in your custom Copr project, diff --git a/docs/configuration/upstream/propose_downstream.md b/docs/configuration/upstream/propose_downstream.md index b45658ea7e..5b679a0699 100644 --- a/docs/configuration/upstream/propose_downstream.md +++ b/docs/configuration/upstream/propose_downstream.md @@ -81,10 +81,8 @@ jobs: This config would update Fedora Rawhide and Fedora 39 dist-git branches. ## Retriggering -Users with write or admin permissions to the repository can retrigger an -update via a comment in any open issue in the upstream repository: - /packit propose-downstream +For retriggering the job, see [retriggering docs](/docs/retriggering#propose_downstream). ## Syncing the release to CentOS Stream diff --git a/docs/configuration/upstream/tests.md b/docs/configuration/upstream/tests.md index a82839c8bc..f1d36333c4 100644 --- a/docs/configuration/upstream/tests.md +++ b/docs/configuration/upstream/tests.md @@ -200,54 +200,10 @@ And there are also pairs of variables for pull-request jobs: Note that some variables do not need to be set if the value is unknown, irrelevant or not-configured. -## Restart Testing - -The testing will automatically start after an update to the pull request -(and successful Copr build if `skip_build` is false). -To trigger retesting manually (can come handy in case of infrastructure -issues for example), you can use the following comment in the pull request: - - /packit test - -Or if you want to re-trigger only failed tests, you can use the following comment -in the pull request: - - /packit retest-failed - -## Running tests with builds from another pull request -It is also possible to run the tests with Copr builds built by Packit in another pull request -(in a different repository). This can be useful when you are working on a change that spans -multiple projects and needs to be tested together. -These tests are possible to trigger only via a comment containing the argument specifying the pull request as: - - /packit test /# - -The requirement is that in the specified PR, there were recent successful builds created by Packit -for the targets configured in the repository with the "main" pull request. -This is a new feature, so the behaviour may be adjusted in the future. -Please reach out back to us for help or with your suggestions. - -## Running tests with a specific identifier -It is possible to run a specific job via `/packit test` command. -The user just needs to specify the argument `--identifier ` and Packit will trigger only the job with this identifier. -The whole command should look like this: `/packit test --identifier my-job-id`. -You can also configure [`test_command.default_identifier`](/docs/configuration#default_identifier) to allow commonly used jobs -to be triggered without the need for manual specification. - -## Running a group of tests with the same label -Users can trigger a specific group of jobs that has a specific value in the list of `labels` option. -The command to pick up these jobs is `/packit test --labels regression,upgrade` where either `regression` or `upgrade` must be present in `labels` option for the job. -The labels should be in the format of comma-separated string. -You can also configure [`test_command.default_labels`](/docs/configuration#default_labels) to allow commonly used job combinations -to be triggered without the need for manual specification. - -## Running tests with specific environment variables -From time to time, you may need to pass specific environment variables to your jobs. -To achieve this, you can use the `--env` option in the comment command `/packit test`, which passes environment variables to Testing Farm. -You can set as many environment variables as you want; you just need to pass `--env `for each one. -For example, you can use the following command `/packit test --env MY_ENV=test --env MY_ENV_2=test_2`. -This command allows you to use `MY_ENV` and `MY_ENV_2` in Testing Farm jobs. -You can also unset an environment variable by not setting its value like `/packit test --env MY_ENV=`. +## Retriggering + +For retriggering the job, see [retriggering docs](/docs/retriggering#tests). + ## Test job statuses By default, while test jobs are waiting for their corresponding build jobs to finish, diff --git a/docs/configuration/upstream/upstream_koji_build.md b/docs/configuration/upstream/upstream_koji_build.md index 35ba5919ea..2326458f72 100644 --- a/docs/configuration/upstream/upstream_koji_build.md +++ b/docs/configuration/upstream/upstream_koji_build.md @@ -40,3 +40,7 @@ the more explicit `upstream_koji_build`.) * **branch** - the name of the branch we want to build for when using **commit** trigger (defaults to the repository's default branch) or target branch when using **pull_request** trigger (default behaviour is reacting to all pull requests in the repository). + +## Retriggering + +For retriggering the job, see [retriggering docs](/docs/retriggering#upstream_koji_build). diff --git a/docs/configuration/upstream/vm_image_build.md b/docs/configuration/upstream/vm_image_build.md index ce8962af73..dd14f3e183 100644 --- a/docs/configuration/upstream/vm_image_build.md +++ b/docs/configuration/upstream/vm_image_build.md @@ -30,6 +30,10 @@ Image builds are only triggered after a collaborator places a comment `/packit vm-image-build` in a pull request. The image builds are **NOT** submitted automatically. This is a subject to change as we improve the integration in future. +## Retriggering + +For retriggering the job, see [retriggering docs](/docs/retriggering#vm_image_build). + ## Example diff --git a/docs/retriggering.md b/docs/retriggering.md index 5989c8c3e2..013c73fd6c 100644 --- a/docs/retriggering.md +++ b/docs/retriggering.md @@ -8,7 +8,7 @@ In general, you can put a `/packit ` comment to trigger the Packit job manually. ### copr_build -So for [Copr builds](/docs/configuration/upstream/copr_build), Packit is able to trigger new builds based on a pull request comment: +For retriggering the [`copr_build`](/docs/configuration/upstream/copr_build) jobs, Packit is able to trigger new builds based on a pull request comment: /packit copr-build @@ -19,10 +19,6 @@ or the shorter version So whenever you run into a flake or feel like you want to retrigger, just type that comment into the PR and enjoy some fine, fresh builds. -It is also possible to re-trigger only the failed builds using a pull request comment - - /packit rebuild-failed - The same can be used to retrigger jobs configured with either `commit` or `release` trigger by specifying the respective arguments, using commit comments: @@ -36,25 +32,22 @@ If no additional arguments are provided, Packit defaults to the commit trigger o default branch. The job will execute only if a corresponding job configuration exists for the specified branch or release and if the commit is included on the specified branch or tag. +It is also possible to re-trigger only the failed builds using a pull request comment + + /packit rebuild-failed + ### propose_downstream -For [`propose_downstream`](/docs/configuration/upstream/propose_downstream), you need to place this comment to any issue: +For retriggering the [`propose_downstream`](/docs/configuration/upstream/propose_downstream) jobs, users with write or admin permissions to +the repository can retrigger an +update via a comment in any open issue in the upstream repository: /packit propose-downstream - ### tests For retriggering the [`tests`](/docs/configuration/upstream/tests) jobs, you can use a pull-request comment: /packit test - - -And to re-trigger only the failed tests, you can use - - /packit retest-failed - -For testing, there is possible to specify also other arguments for more advanced use-cases, see -the details [here](/docs/configuration/upstream/tests#running-tests-with-builds-from-another-pull-request). The same can be used to retrigger jobs configured with either `commit` or `release` trigger by specifying the respective arguments, using commit comments: @@ -65,10 +58,50 @@ or /packit test --release + If no additional arguments are provided, Packit defaults to the commit trigger on the repository's default branch. The job will execute only if a corresponding job configuration exists for the specified branch or release and if the commit is included on the specified branch or tag. +And to re-trigger only the failed tests in pull request, you can use + + /packit retest-failed + +#### Running tests with builds from another pull request +It is also possible to run the tests with Copr builds built by Packit in another pull request +(in a different repository). This can be useful when you are working on a change that spans +multiple projects and needs to be tested together. +These tests are possible to trigger only via a comment containing the argument specifying the pull request as: + + /packit test /# + +The requirement is that in the specified PR, there were recent successful builds created by Packit +for the targets configured in the repository with the "main" pull request. +This is a new feature, so the behaviour may be adjusted in the future. +Please reach out back to us for help or with your suggestions. + +#### Running tests with a specific identifier +It is possible to run a specific job via `/packit test` command. +The user just needs to specify the argument `--identifier ` and Packit will trigger only the job with this identifier. +The whole command should look like this: `/packit test --identifier my-job-id`. +You can also configure [`test_command.default_identifier`](/docs/configuration#default_identifier) to allow commonly used jobs +to be triggered without the need for manual specification. + +#### Running a group of tests with the same label +Users can trigger a specific group of jobs that has a specific value in the list of `labels` option. +The command to pick up these jobs is `/packit test --labels regression,upgrade` where either `regression` or `upgrade` must be present in `labels` option for the job. +The labels should be in the format of comma-separated string. +You can also configure [`test_command.default_labels`](/docs/configuration#default_labels) to allow commonly used job combinations +to be triggered without the need for manual specification. + +#### Running tests with specific environment variables +From time to time, you may need to pass specific environment variables to your jobs. +To achieve this, you can use the `--env` option in the comment command `/packit test`, which passes environment variables to Testing Farm. +You can set as many environment variables as you want; you just need to pass `--env `for each one. +For example, you can use the following command `/packit test --env MY_ENV=test --env MY_ENV_2=test_2`. +This command allows you to use `MY_ENV` and `MY_ENV_2` in Testing Farm jobs. +You can also unset an environment variable by not setting its value like `/packit test --env MY_ENV=`. + ### upstream_koji_build For retriggering the [`upstream_koji_build`](/docs/configuration/upstream/upstream_koji_build) jobs, you can @@ -79,40 +112,34 @@ again use a pull-request comment: ### vm_image_build [VM Image builds](/docs/configuration/upstream/vm_image_build) are not triggered automatically at all. -To trigger them, you need to post a pull-request comment: +To trigger them, users with write access to the repository need to post a pull-request comment: /packit vm-image-build every time. - -:::caution - -The requirements stated [above](#approval) apply, so if you see this message - - Only users with write or admin permissions to the repository can trigger - Packit-as-a-Service - -it means the author of the comment does not have write access to the -repository so the build cannot be scheduled. This is a perfect case for -maintainers of the repository to post `/packit build` in the PR to get a build. - -::: - ### pull_from_upstream -Packagers can retrigger the job +For retriggering the [`pull_from_upstream`](/docs/configuration/downstream/pull_from_upstream) jobs, packagers can retrigger the job via a comment in any dist-git pull request: /packit pull-from-upstream This will take the Packit configuration file from the default branch of the dist-git - repository (`rawhide`), same as if the job was triggered by a new release. To use the configuration file from the dist-git pull request you are commenting on, you can add an argument: + repository (`rawhide`), same as if the job was triggered by a new release. +You can monitor the job in [Packit Dashboard](https://dashboard.packit.dev/jobs/pull-from-upstreams). +To use the configuration file from the dist-git pull request you are commenting on, you can add an argument: /packit pull-from-upstream --with-pr-config +`pull-from-upstream` automatically handles the Bugzilla created by Upstream +Release Monitoring (by default adds `Resolves` to changelog/commit and exposes `PACKIT_RESOLVED_BUGS` to the `changelog-entry` and `commit-message` +actions). If you want to override the referenced resolved bug set by Packit, you can retrigger `pull_from_upstream` like this: + + /packit pull-from-upstream --resolve-bug rhbz#123,rhbz#124 + ### koji_build -Packagers can retrigger a build by a comment in a dist-git pull request: +For retriggering the [`koji_build`](/docs/configuration/downstream/koji_build) jobs, packagers can retrigger a build by a comment in a dist-git pull request: /packit koji-build @@ -123,7 +150,7 @@ If Packit created an issue in the configured `issue_repository`, you can place t issue to retrigger the builds (see [`issue_repository`](/docs/configuration#issue_repository) for details). ### bodhi_update -Packagers with write access to the dist-git repository can retrigger an update by a comment in a dist-git pull request: +For retriggering the [`bodhi_update`](/docs/configuration/downstream/bodhi_update) jobs, packagers with write access to the dist-git repository can retrigger an update by a comment in a dist-git pull request: /packit create-update