|
| 1 | +--- |
| 2 | +title: Retriggering |
| 3 | +sidebar_position: 7 |
| 4 | +--- |
| 5 | + |
| 6 | +## Comments |
| 7 | +In general, you can put a `/packit <job-you-want-to-trigger>` comment |
| 8 | +to trigger the Packit job manually. |
| 9 | + |
| 10 | +### copr_build |
| 11 | +So for [Copr builds](/docs/configuration/upstream/copr_build), Packit is able to trigger new builds based on a pull request comment: |
| 12 | + |
| 13 | + /packit copr-build |
| 14 | + |
| 15 | +or the shorter version |
| 16 | + |
| 17 | + /packit build |
| 18 | + |
| 19 | +So whenever you run into a flake or feel like you want to retrigger, just type |
| 20 | +that comment into the PR and enjoy some fine, fresh builds. |
| 21 | + |
| 22 | +It is also possible to re-trigger only the failed builds using a pull request comment |
| 23 | + |
| 24 | + /packit rebuild-failed |
| 25 | + |
| 26 | +The same can be used to retrigger jobs configured with either `commit` or `release` |
| 27 | +trigger by specifying the respective arguments, using commit comments: |
| 28 | + |
| 29 | + /packit build --commit <branch-name> |
| 30 | + |
| 31 | +or |
| 32 | + |
| 33 | + /packit build --release <tag-name> |
| 34 | + |
| 35 | +If no additional arguments are provided, Packit defaults to the commit trigger on the repository's |
| 36 | +default branch. The job will execute only if a corresponding job configuration exists for the |
| 37 | +specified branch or release and if the commit is included on the specified branch or tag. |
| 38 | + |
| 39 | +### propose_downstream |
| 40 | +For [`propose_downstream`](/docs/configuration/upstream/propose_downstream), you need to place this comment to any issue: |
| 41 | + |
| 42 | + /packit propose-downstream |
| 43 | + |
| 44 | + |
| 45 | +### tests |
| 46 | + |
| 47 | +For retriggering the [`tests`](/docs/configuration/upstream/tests) jobs, you can use a pull-request comment: |
| 48 | + |
| 49 | + /packit test |
| 50 | + |
| 51 | + |
| 52 | +And to re-trigger only the failed tests, you can use |
| 53 | + |
| 54 | + /packit retest-failed |
| 55 | + |
| 56 | +For testing, there is possible to specify also other arguments for more advanced use-cases, see |
| 57 | +the details [here](/docs/configuration/upstream/tests#running-tests-with-builds-from-another-pull-request). |
| 58 | + |
| 59 | +The same can be used to retrigger jobs configured with either `commit` or `release` |
| 60 | +trigger by specifying the respective arguments, using commit comments: |
| 61 | + |
| 62 | + /packit test --commit <branch-name> |
| 63 | + |
| 64 | +or |
| 65 | + |
| 66 | + /packit test --release <tag-name> |
| 67 | + |
| 68 | +If no additional arguments are provided, Packit defaults to the commit trigger on the repository's |
| 69 | +default branch. The job will execute only if a corresponding job configuration exists for the |
| 70 | +specified branch or release and if the commit is included on the specified branch or tag. |
| 71 | + |
| 72 | +### upstream_koji_build |
| 73 | + |
| 74 | +For retriggering the [`upstream_koji_build`](/docs/configuration/upstream/upstream_koji_build) jobs, you can |
| 75 | +again use a pull-request comment: |
| 76 | + |
| 77 | + /packit upstream-koji-build |
| 78 | + |
| 79 | +### vm_image_build |
| 80 | + |
| 81 | +[VM Image builds](/docs/configuration/upstream/vm_image_build) are not triggered automatically at all. |
| 82 | +To trigger them, you need to post a pull-request comment: |
| 83 | + |
| 84 | + /packit vm-image-build |
| 85 | + |
| 86 | +every time. |
| 87 | + |
| 88 | + |
| 89 | +:::caution |
| 90 | + |
| 91 | +The requirements stated [above](#approval) apply, so if you see this message |
| 92 | + |
| 93 | + Only users with write or admin permissions to the repository can trigger |
| 94 | + Packit-as-a-Service |
| 95 | + |
| 96 | +it means the author of the comment does not have write access to the |
| 97 | +repository so the build cannot be scheduled. This is a perfect case for |
| 98 | +maintainers of the repository to post `/packit build` in the PR to get a build. |
| 99 | + |
| 100 | +::: |
| 101 | + |
| 102 | +### pull_from_upstream |
| 103 | +Packagers can retrigger the job |
| 104 | +via a comment in any dist-git pull request: |
| 105 | + |
| 106 | + /packit pull-from-upstream |
| 107 | + |
| 108 | +This will take the Packit configuration file from the default branch of the dist-git |
| 109 | + 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: |
| 110 | + |
| 111 | + /packit pull-from-upstream --with-pr-config |
| 112 | + |
| 113 | +### koji_build |
| 114 | + |
| 115 | +Packagers can retrigger a build by a comment in a dist-git pull request: |
| 116 | + |
| 117 | + /packit koji-build |
| 118 | + |
| 119 | +The build will be triggered for the target branch of the pull request using the most recent commit on the target branch |
| 120 | +(NOT the HEAD commit of the pull request). |
| 121 | + |
| 122 | +If Packit created an issue in the configured `issue_repository`, you can place the same comment in that |
| 123 | +issue to retrigger the builds (see [`issue_repository`](/docs/configuration#issue_repository) for details). |
| 124 | + |
| 125 | +### bodhi_update |
| 126 | +Packagers with write access to the dist-git repository can retrigger an update by a comment in a dist-git pull request: |
| 127 | + |
| 128 | + /packit create-update |
| 129 | + |
| 130 | +The update will be triggered for the target branch of the pull request. |
| 131 | + |
| 132 | +If Packit created an issue in the configured `issue_repository`, you can place the same comment in that |
| 133 | +issue to retrigger the updates (see [`issue_repository`](/docs/configuration#issue_repository) for details). |
| 134 | + |
| 135 | + |
| 136 | +## GitHub Checks UI |
| 137 | +In GitHub Checks interface, it is also possible to re-trigger a specific task just by clicking on `Re-run` |
| 138 | +for the particular check: |
| 139 | + |
| 140 | + |
| 141 | + |
| 142 | +The button is available only for users with write permissions to the repository. |
0 commit comments