fix(release-please): serialize runs per repo with a concurrency group - #39
Closed
kojiromike wants to merge 3 commits into
Closed
kojiromike wants to merge 3 commits into
kojiromike wants to merge 3 commits into
Conversation
GitHub occasionally delivers a single push to main as two workflow runs. Both runs build the identical release commit, and whichever loses the race fails with "Error updating ref heads/release-please--branches--main--...", leaving a red run on main even though the release PR is correct (chart-oce-openemr run 36780271346). Put the job in a repo-wide concurrency group without cancel-in-progress so the second run queues, then no-ops against the already-updated PR. Group per repo rather than per ref because release-please always targets the default branch, and use a name callers won't reuse to avoid a caller/callee deadlock. Assisted-by: Claude Code
The concurrency group's comment and README paragraph said overlapping runs queue. GitHub keeps only one pending run per group, so a third overlapping run cancels the one already waiting, and the canceled run shows as a failed check on its commit. No release work is lost, because release-please reads the default branch's current HEAD rather than the triggering commit, but callers should expect the canceled run. `queue: max` raises the limit to 100 pending runs. actionlint rejects the key today, so that change is tracked in #40. Also drop the claim that the group name is distinct from any name a caller might declare. Nothing enforces that; the README warning is the only guard. Assisted-by: Claude Code
The job had no timeout, so it inherited GitHub's 360-minute default. That was harmless while runs were independent. Now that the job holds a repo-wide concurrency group, a hung run would stall every later release PR update and release in that repo for up to six hours. Cap the job at 30 minutes. The longest job in the last 100 Release Please runs of any caller took 277 seconds, so the cap leaves about six times that. Assisted-by: Claude Code
Contributor
Author
|
Self-reviewed: 5 local passes (3 author, 2 independent) at
|
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.
GitHub sometimes starts this workflow twice for a single push to
main. Both runs build the same release commit, and the slower one fails withError updating ref heads/release-please--branches--main--.... That leaves a red run onmaineven though the release PR is correct. Example: chart-oce-openemr run 36780271346 vs. its twin 36780270472.This change puts the reusable job in a repo-wide
release-please-reusableconcurrency group withoutcancel-in-progress. The second run then waits and finds nothing left to update.concurrencygroup.queue: maxraises the limit to 100 pending runs, but actionlint rejects the key today (release-please: usequeue: maxon the concurrency group once actionlint accepts it #40).After the next release, Dependabot opens a pin bump in the 21 callers whose Dependabot config covers
github-actions. The other 22 (thetfm-*modules, fourchart-oce-*charts and twooce-py-*tools, pinned at@1.0.0or@1.0.2) have no such config and need a manual bump.