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.

Author: lbarcziova

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

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

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
 

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,

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

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,

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).

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
 

docs/retriggering.md

@@ -8,7 +8,7 @@ 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:
+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 <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.
 
+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 <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=`.
+
 ### 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