feat(ci): cancel in-progress PR workflows on new commit push#20265
Closed
feat(ci): cancel in-progress PR workflows on new commit push#20265
Conversation
Contributor
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Cloudflare
Core
Deps
Other
Bug Fixes 🐛Deno
Other
Internal Changes 🔧Ci
Deps
Other
🤖 This preview updates automatically when you update the PR. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5491706. Configure here.
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
Concurrency cancellation risks cancelling release preparation workflow
Medium Severity
Adding cancel-in-progress: true to auto-release.yml is risky and doesn't serve the PR's stated purpose. This workflow only triggers on pull_request: types: [closed], so there's no "new commit push" scenario that would benefit from concurrency cancellation. However, if someone manually re-runs this workflow while the original is still executing (e.g., thinking it's stuck), the concurrency group (keyed on github.head_ref) would cancel the in-progress release preparation via craft, potentially leaving the release in an inconsistent state.
Reviewed by Cursor Bugbot for commit 5491706. Configure here.
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
Unnecessary concurrency on closed-only and opened-only workflows
Low Severity
The concurrency cancellation added to cleanup-pr-caches.yml (triggers only on closed) and gitflow-merge-conflict.yml (triggers only on opened) serves no practical purpose. These event types fire at most once per PR lifecycle, so there are no "in-progress" runs to cancel when a new commit is pushed. This adds configuration noise without matching the PR's stated intent of cancelling workflows on new commit pushes.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 5491706. Configure here.
Contributor
size-limit report 📦
|
Member
Author
|
we're already good here |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
this adds concurrency cancellation to pull_request workflows so that pushing a new commit to a PR automatically cancels any still-running workflow from the previous commit
99% of the time if you push a new commit you don't care about the previous workflow if its still running
we already do this for all sentry+getsentry pull_request workflows
we (devinfra) can't measure this yet but this would greatly help decrease org-wide runner queue pressure!