packit · softwarefactory-project-zuul · Apr 16, 2025 · Apr 15, 2025 · Apr 15, 2025 · Apr 15, 2025
diff --git 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 [our release guide](/docs/fedora-releases-guide/dist-git-onboarding#retriggering).
-
 :::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
@@ -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,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 [our release guide](/docs/fedora-releases-guide/dist-git-onboarding#retriggering).
-
 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
@@ -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/index.md b/docs/configuration/index.md
@@ -1,6 +1,6 @@
 ---
 title: Configuration
-sidebar_position: 7
+sidebar_position: 6
 ---
 
 # Configuration

diff --git 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
@@ -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
@@ -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 <namespace>/<repo>#<pr_id>
-
-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 <job_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
@@ -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
@@ -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/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
-```
+```
diff --git 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/docs/guide.md b/docs/guide.md
@@ -453,118 +453,12 @@ 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 <job-you-want-to-trigger>` 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 <branch-name>
-
-or
-
-    /packit build --release <tag-name>
-
-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 <branch-name>
-
-or
-
-    /packit test --release <tag-name>
-
-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.
 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).
diff --git 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.