Retriggering refactor (#1031)

Retriggering refactor

Fixes #1027

Reviewed-by: Matej Focko

Author: softwarefactory-project-zuul[bot]

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

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

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/index.md

@@ -1,6 +1,6 @@
 ---
 title: Configuration
-sidebar_position: 7
+sidebar_position: 6
 ---
 
 # Configuration

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/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
-```
+```