Repository navigation
fix(ci): stop comment runs from evicting the release push run - #585
Merged
Merged
Conversation
A merge to main fires two release runs at once: the push, and an issue_comment from whichever bot comments on the PR. Both resolve `github.ref_name` to the default branch, so the workflow-level concurrency group held both. `cancel-in-progress: false` only protects a run already in progress — a pending run is evicted when a newer one joins the group, so the comment run displaced the push run before it started a single job. Only the push run releases; every comment run has `check` gate both mutating jobs off. Merging #581 hit this: the push run was cancelled with zero jobs, CI stayed green, and the release branch silently kept the prior commit. The group moves to `pull-request` and `release`, which are what actually push the release branch. They share one group so they stay mutually exclusive, and a job gated off by `check` never joins it, so a no-op comment run has nothing to displace. Signed-off-by: Rhuan Barreto <rhuan@barreto.work>
|
Important Approval pendingCodeRabbit has no unresolved comments, but it could not review the latest commit because the review limit was reached. Follow the review guidance in this comment to continue. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Deploying archgate-cli with
|
| Latest commit: |
1a93314
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://6ee680bf.archgate-cli.pages.dev |
| Branch Preview URL: | https://claude-release-workflow-conc.archgate-cli.pages.dev |
rhuanbarreto
commented
Aug 22, 2026
Contributor
Code Coverage
Full HTML report available in workflow artifacts. Per-directory breakdown
|
GEN-004 keeps comments to current behaviour and leaves the why to commits and PRs, which already carry it. The per-job notes on the shared group stay: they describe what the group does, not how it got there. Signed-off-by: Rhuan Barreto <rhuan@barreto.work>
Contributor
Author
|
@coderabbitai approve |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
✅ Action performedComments resolved and changes approved. |
rhuanbarreto
enabled auto-merge (squash)
August 22, 2026 13:41
Merged
rhuanbarreto
pushed a commit
that referenced
this pull request
Aug 22, 2026
# archgate ## [0.55.0](v0.54.0...v0.55.0) (2026-08-22) ### Features * **bun:** adopt Bun 1.4 archive, test parallelism, and terminal APIs ([#576](#576)) ([22715ee](22715ee)) ### Bug Fixes * **ci:** stop comment runs from evicting the release push run ([#585](#585)) ([9a3c881](9a3c881)), references [#581](#581) [#575](#575) * **fs:** survive Bun 1.4's rejecting-read regression, and upgrade to 1.4.0 ([#574](#574)) ([51f7ffc](51f7ffc)) * **session-context:** report a read failure instead of throwing it ([#577](#577)) ([94ffdcd](94ffdcd)), references [#576](#576) [#574](#574) [#576](#576) * **session-context:** truncate previews on grapheme boundaries ([#581](#581)) ([cc8d93c](cc8d93c)) --- This PR was generated with [simple-release](https://github.com/TrigenSoftware/simple-release). <details> <summary>📄 Cheatsheet</summary> <br> You can configure the bot's behavior through a pull request comment using the `!simple-release/set-options` command. ### Command Format ````md !simple-release/set-options ```json { "bump": {}, "publish": {} } ``` ```` ### Useful Parameters #### Bump | Parameter | Type | Description | |-----------|------|-------------| | `version` | `string` | Force set specific version | | `as` | `'major' \| 'minor' \| 'patch' \| 'prerelease'` | Release type | | `prerelease` | `string` | Pre-release identifier (e.g., "alpha", "beta") | | `firstRelease` | `boolean` | Whether this is the first release | | `skip` | `boolean` | Skip version bump | | `byProject` | `Record<string, object>` | Per-project bump options for monorepos | #### Publish | Parameter | Type | Description | |-----------|------|-------------| | `skip` | `boolean` | Skip publishing | | `access` | `'public' \| 'restricted'` | Package access level | | `tag` | `string` | Tag for npm publication | ### Usage Examples #### Force specific version ````md !simple-release/set-options ```json { "bump": { "version": "2.0.0" } } ``` ```` #### Force major bump ````md !simple-release/set-options ```json { "bump": { "as": "major" } } ``` ```` #### Create alpha pre-release ````md !simple-release/set-options ```json { "bump": { "prerelease": "alpha" } } ``` ```` #### Publish with specific access and tag ````md !simple-release/set-options ```json { "bump": { "prerelease": "beta" }, "publish": { "access": "public", "tag": "beta" } } ``` ```` ### Custom Changelog Preamble You can add custom markdown to the top of the changelog (right after the version header) using the `!simple-release/set-preamble` command. The markdown after the command line becomes the preamble. ```md !simple-release/set-preamble ## What's new? - The website was completely redesigned - The new API gives you awesome possibilities ``` In a monorepo, pass the full package name after the command to target a single package's changelog. Wrap the name in backticks so GitHub keeps it as text instead of a mention: ```md !simple-release/set-preamble `@your-org/core` ## Core changes - New plugin system ``` Use one comment per package, plus one without a name for the whole release. ### Access Restrictions The commands can only be used by users with permissions: - repository owner - organization member - collaborator ### Notes - The last comment with `!simple-release/set-options` command takes priority - The last `!simple-release/set-preamble` comment per package takes priority - JSON must be valid, otherwise the `set-options` command will be ignored - Parameters apply only to the current release execution - The commands can be updated by editing the comment or adding a new one </details> <!-- Please do not edit this comment. simple-release-pull-request: true simple-release-branch-from: release simple-release-branch-to: main --> Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
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
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.
What happened
Merging #581 did not update the release branch. CI was green, the merge was clean, and the release workflow reported success — but release stayed on the prior commit.
The merge fired two release runs in the same second:
Both resolve
github.ref_nameto the default branch, so the workflow-level group held both:cancel-in-progress: falseonly protects a run already in progress. A pending run is evicted when a newer one joins the group, so theissue_commentrun displaced thepushrun before it started a single job.That matters because only the push run releases. Across the last 8 runs, every
issue_commentrun skipped both mutating jobs; the run that cut 0.55.0 wasevent=push:It fails silently — no red check anywhere, just a missing release.
Why it recurs
Not a one-off. A bot comments on essentially every merged PR, so any comment landing within seconds of a push to main evicts the release run.
The fix
The group moves from the workflow to the two jobs that actually push the release branch,
pull-requestandrelease. Both keep one shared group, so they stay mutually exclusive with each other. A job gated off bychecknever joins the group, so a no-op comment run has nothing to displace.Two-push ordering is unaffected: if a later merge evicts an earlier pending
pull-requestjob, the surviving run is based on a newer main and covers both commits.Already remediated separately
The lost run for
cc8d93cwas re-run manually, so the release branch is caught up —a452945 chore(release): 0.55.0now sits on top ofcc8d93c, 0 behind main, and #575 carries the changelog entry. This PR prevents the next occurrence.Testing
Workflow parses;
concurrencyis absent at workflow level and present on both mutating jobs with the shared group. actionlint and zizmor run on this path in CI.