fix: /ok-to-test /retest pipelineruns should not be created if last sha successful #2048
+402
−64
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
waveywaves
force-pushed
the
execute-non-successful
branch
9 times, most recently
from
fa2a595 to
72e4aca
Compare
|
/cancel |
waveywaves
force-pushed
the
execute-non-successful
branch
2 times, most recently
from
579fd77 to
7508871
Compare
waveywaves
changed the title
There was a problem hiding this comment.
Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (1)
pkg/pipelineascode/pipelineascode.go:196
- [nitpick] Consider renaming the variable 'existingPRs' (later in the block) to 'existingRuns' or similar to more clearly indicate that it represents a collection of PipelineRun objects.
labelSelector := fmt.Sprintf("%s=%s", keys.SHA, formatting.CleanValueKubernetes(p.event.SHA))
|
/retest |
waveywaves
force-pushed
the
execute-non-successful
branch
5 times, most recently
from
8f5c0ab to
b44e208
Compare
|
cc @chmouel seems like the provider e2e tests are not running :/ wanted to test them, not sure what's up |
|
cc @zakisk |
zakisk
reviewed
Apr 21, 2025
waveywaves
force-pushed
the
execute-non-successful
branch
9 times, most recently
from
fe82231 to
95d7ede
Compare
zakisk
force-pushed
the
execute-non-successful
branch
2 times, most recently
from
4f3915b to
e1d965f
Compare
zakisk
reviewed
Aug 12, 2025
| @@ -23,7 +23,7 @@ or other supported Git providers (currently GitHub and Gitea). | |||
| to trigger the CI for a pull request by commenting `/ok-to-test`. This enables | |||
| CI to run on pull requests submitted by contributors who are not collaborators | |||
| of the repository or organization. It also applies to `/test` and `/retest` | |||
| commands. This action takes precedence over the `pull_request` action. | |||
| commands. Note that `/retest` will only create new PipelineRuns if previous runs failed. This action takes precedence over the `pull_request` action. | |||
There was a problem hiding this comment.
Suggested change
| commands. Note that `/retest` will only create new PipelineRuns if previous runs failed. This action takes precedence over the `pull_request` action. | |
| commands. Note that `/retest` will only trigger failed PipelineRuns. This action takes precedence over the `pull_request` action. |
zakisk
reviewed
Aug 12, 2025
| @@ -35,7 +35,7 @@ tracking using a Git workflow. | |||
|
|
|||
| <---> | |||
|
|
|||
| - Pull-request "*GitOps*" actions through comments with `/retest`, `/test <pipeline-name>` and so on. | |||
| - Pull-request "*GitOps*" actions through comments with `/retest` (reruns failed pipelines), `/test <pipeline-name>` (force rerun specific pipeline) and so on. | |||
There was a problem hiding this comment.
Suggested change
| - Pull-request "*GitOps*" actions through comments with `/retest` (reruns failed pipelines), `/test <pipeline-name>` (force rerun specific pipeline) and so on. | |
| - Pull-request "*GitOps*" actions through comments with `/retest` (reruns failed PipelineRuns), `/test <pipeline-name>` (force rerun specific PipelineRun) and so on. |
zakisk
reviewed
Aug 12, 2025
| @@ -10,7 +10,7 @@ The advantage of using a `GitOps command` is that it provides a journal of all t | |||
|
|
|||
| ## GitOps Commands on Pull Requests | |||
|
|
|||
| For example, when you are on a Pull Request, you may want to restart all your PipelineRuns. To do so, you can add a comment on your Pull Request starting with `/retest`, and all PipelineRuns attached to that Pull Request will be restarted. | |||
| For example, when you are on a Pull Request, you may want to restart failed PipelineRuns. To do so, you can add a comment on your Pull Request starting with `/retest`, and all **failed** PipelineRuns attached to that Pull Request will be restarted. If all previous PipelineRuns for the same commit were successful, no new PipelineRuns will be created to avoid unnecessary duplication. | |||
There was a problem hiding this comment.
Suggested change
| For example, when you are on a Pull Request, you may want to restart failed PipelineRuns. To do so, you can add a comment on your Pull Request starting with `/retest`, and all **failed** PipelineRuns attached to that Pull Request will be restarted. If all previous PipelineRuns for the same commit were successful, no new PipelineRuns will be created to avoid unnecessary duplication. | |
| For example, when you are on a Pull Request, you may want to trigger failed PipelineRuns. To do so, you can add a comment on your Pull Request starting with `/retest`, and all **failed** PipelineRuns attached to that Pull Request will be triggered. If all previous PipelineRuns for the same commit were successful, no new PipelineRuns will be triggered to avoid unnecessary duplication. |
There was a problem hiding this comment.
@waveywaves here and all other places in docs you've updated, I see you're mentioning only /retest command but /test does the same. do you mind adding it as well in examples and wherever needed?
zakisk
reviewed
Aug 12, 2025
| @@ -21,6 +21,21 @@ failure is not with your PR but seems to be an infrastructure issue. | |||
| /retest | |||
| ``` | |||
|
|
|||
| The `/retest` command will only create new PipelineRuns if: | |||
| - Previous PipelineRuns for the same commit **failed**, OR | |||
There was a problem hiding this comment.
Suggested change
| - Previous PipelineRuns for the same commit **failed**, OR | |
| - Previously **failed** PipelineRuns for the same commit, OR |
zakisk
reviewed
Aug 12, 2025
| @@ -21,6 +21,21 @@ failure is not with your PR but seems to be an infrastructure issue. | |||
| /retest | |||
| ``` | |||
|
|
|||
| The `/retest` command will only create new PipelineRuns if: | |||
| - Previous PipelineRuns for the same commit **failed**, OR | |||
| - No PipelineRuns exist for the same commit | |||
There was a problem hiding this comment.
Suggested change
| - No PipelineRuns exist for the same commit | |
| - No PipelineRun has been run for the same commit yet |
zakisk
reviewed
Aug 12, 2025
| - Previous PipelineRuns for the same commit **failed**, OR | ||
| - No PipelineRuns exist for the same commit | ||
|
|
||
| If a successful PipelineRun already exists for the same commit, `/retest` will **skip** creating a new PipelineRun to avoid unnecessary duplication. |
There was a problem hiding this comment.
Suggested change
| If a successful PipelineRun already exists for the same commit, `/retest` will **skip** creating a new PipelineRun to avoid unnecessary duplication. | |
| If a successful PipelineRun already exists for the same commit, `/retest` will **skip** triggering a new PipelineRun to avoid unnecessary duplication. |
There was a problem hiding this comment.
@waveywaves trigger is appropriate term I guess
zakisk
reviewed
Aug 12, 2025
| /retest <pipelinerun-name> | ||
| ``` | ||
|
|
||
| This will always create a new PipelineRun, even if previous runs were successful. |
There was a problem hiding this comment.
Suggested change
| This will always create a new PipelineRun, even if previous runs were successful. | |
| This will always trigger a new PipelineRun, even if previous runs were successful. |
zakisk
reviewed
Aug 12, 2025
|
|
||
| This will always create a new PipelineRun, even if previous runs were successful. | ||
|
|
||
| Similar to `/retest`, the `/ok-to-test` command will only create new PipelineRuns if no successful PipelineRun already exists for the same commit. This prevents duplicate runs when repository owners repeatedly approve the same commit. |
There was a problem hiding this comment.
Suggested change
| Similar to `/retest`, the `/ok-to-test` command will only create new PipelineRuns if no successful PipelineRun already exists for the same commit. This prevents duplicate runs when repository owners repeatedly approve the same commit. | |
| Similar to `/retest`, the `/ok-to-test` command will only trigger new PipelineRuns if no successful PipelineRun already exists for the same commit. This prevents duplicate runs when repository owners repeatedly test the same commit by `/test` and `/retest` command. |
zakisk
reviewed
Aug 12, 2025
| @@ -255,12 +270,12 @@ Here are the possible event types: | |||
|
|
|||
| * `test-all-comment`: The event is a single `/test` that would test every matched PipelineRun. | |||
| * `test-comment`: The event is a `/test <PipelineRun>` comment that would test a specific PipelineRun. | |||
| * `retest-all-comment`: The event is a single `/retest` that would retest every matched PipelineRun. | |||
| * `retest-all-comment`: The event is a single `/retest` that would retest every matched **failed** PipelineRun. If a successful PipelineRun already exists for the same commit, no new PipelineRun will be created. | |||
There was a problem hiding this comment.
Suggested change
| * `retest-all-comment`: The event is a single `/retest` that would retest every matched **failed** PipelineRun. If a successful PipelineRun already exists for the same commit, no new PipelineRun will be created. | |
| * `retest-all-comment`: The event is a single `/retest` that would retest every matched **failed** PipelineRun. If a successful PipelineRun already exists for the same commit, no new PipelineRun will be triggered. |
zakisk
reviewed
Aug 12, 2025
| * `retest-comment`: The event is a `/retest <PipelineRun>` that would retest a specific PipelineRun. | ||
| * `on-comment`: The event is coming from a custom comment that would trigger a PipelineRun. | ||
| * `cancel-all-comment`: The event is a single `/cancel` that would cancel every matched PipelineRun. | ||
| * `cancel-comment`: The event is a `/cancel <PipelineRun>` that would cancel a specific PipelineRun. | ||
| * `ok-to-test-comment`: The event is a `/ok-to-test` that would allow running the CI for an unauthorized user. | ||
| * `ok-to-test-comment`: The event is a `/ok-to-test` that would allow running the CI for an unauthorized user. If a successful PipelineRun already exists for the same commit, no new PipelineRun will be created. |
There was a problem hiding this comment.
Suggested change
| * `ok-to-test-comment`: The event is a `/ok-to-test` that would allow running the CI for an unauthorized user. If a successful PipelineRun already exists for the same commit, no new PipelineRun will be created. | |
| * `ok-to-test-comment`: The event is a `/ok-to-test` that would allow running the CI for an unauthorized user. If a successful PipelineRun already exists for the same commit, no new PipelineRun will be triggered. |
zakisk
reviewed
Aug 12, 2025
| @@ -72,8 +72,10 @@ get_tests() { | |||
| mapfile -t testfiles < <(find test/ -maxdepth 1 -name '*.go') | |||
| ghglabre="Github|Gitlab|Bitbucket" | |||
| if [[ ${target} == "providers" ]]; then | |||
| # echo "TestGithubMaxKeepRuns" | |||
There was a problem hiding this comment.
@waveywaves I think this is added mistakenly?
|
/test linters |
…ipelineruns when executing /ok-to-test or /retest gitops commands, check whether the last pipelinerun created for the same SHA was successful. If the run was successful, skip new pipelinerun creation - Add checkForExistingSuccessfulPipelineRun logic to prevent creating duplicate PipelineRuns when /retest or /ok-to-test commands are used and a successful PipelineRun already exists for the same SHA - Fix cancel-in-progress flow by short-circuiting PullRequestClosed events to avoid interference with matching logic - Ensure /retest <pipelinerun-name> commands always create new PipelineRuns as explicitly requested by users - Add GetOriginalPipelineRunName helper function to eliminate duplicate logic across test files for finding PipelineRun names - Fix multiple tests that incorrectly used plain /retest expecting multiple PipelineRuns: now use /retest <name> for forced reruns - Update max-keep-runs tests to use specific PipelineRun names for proper testing of cleanup functionality - Fix timing issues in tests by adding proper waits for Repository CRD updates
zakisk
force-pushed
the
execute-non-successful
branch
from
e1d965f to
53877c2
Compare
|
/test linters |
|
@waveywaves linters is failing due to docs changes, please address them! |
|
@waveywaves I've tested it and it is not working as expected. I had 4 failed PipelineRuns in my test PR when I did Screencast.From.2025-08-12.15-44-20.mp4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
Add checkForExistingSuccessfulPipelineRun logic to prevent creating duplicate
PipelineRuns when /retest or /ok-to-test commands are used and a
successful PipelineRun already exists for the same SHA
Fix cancel-in-progress flow by short-circuiting PullRequestClosed events
to avoid interference with matching logic
Ensure /retest commands always create new PipelineRuns
as explicitly requested by users
Add GetOriginalPipelineRunName helper function to eliminate duplicate
logic across test files for finding PipelineRun names
Fix multiple tests that incorrectly used plain /retest expecting multiple
PipelineRuns: now use /retest for forced reruns
Update max-keep-runs tests to use specific PipelineRun names for proper
testing of cleanup functionality
Fix timing issues in tests by adding proper waits for Repository CRD updates
fixes #1959
Submitter Checklist
📝 Ensure your commit message is clear and informative. Refer to the How to write a git commit message guide. Include the commit message in the PR body rather than linking to an external site (e.g., Jira ticket).
♽ Run make test lint before submitting a PR to avoid unnecessary CI processing. Consider installing pre-commit and running pre-commit install in the repository root for an efficient workflow.
✨ We use linters to maintain clean and consistent code. Run make lint before submitting a PR. Some linters offer a --fix mode, executable with make fix-linters (ensure markdownlint and golangci-lint are installed).
📖 Document any user-facing features or changes in behavior.
🧪 While 100% coverage isn't required, we encourage unit tests for code changes where possible.
🎁 If feasible, add an end-to-end test. See README for details.
🔎 Address any CI test flakiness before merging, or provide a valid reason to bypass it (e.g., token rate limitations).
If adding a provider feature, fill in the following details:
(update the provider documentation accordingly)