Skip to content

ci: scope release concurrency group per branch#15519

Merged
gr2m merged 2 commits into
mainfrom
ci/release-concurrency-per-branch
May 21, 2026
Merged

ci: scope release concurrency group per branch#15519
gr2m merged 2 commits into
mainfrom
ci/release-concurrency-per-branch

Conversation

@gr2m
Copy link
Copy Markdown
Collaborator

@gr2m gr2m commented May 21, 2026

Summary

  • Change concurrency.group in .github/workflows/release.yml from a single global 'release' to 'release-${{ github.ref }}' so each release branch (main, release-v6.0, release-v5.0) gets its own concurrency slot.

Why

Today all three Release runs share one concurrency group. With cancel-in-progress: false, GitHub queues at most one pending run per group — so when three pushes arrive in quick succession (as happened today on #15509, #15513, #15517), the middle pending run gets bumped out of the queue and canceled. Run 26246209250 was canceled this way.

Scoping the group per branch lets each branch's Release workflow run independently while still serializing runs within a single branch.

Test plan

  • Mirror change on release-v6.0 and release-v5.0 branches
  • Confirm subsequent overlapping pushes across branches no longer cancel each other

@gr2m gr2m merged commit 5a0a160 into main May 21, 2026
43 checks passed
@gr2m gr2m deleted the ci/release-concurrency-per-branch branch May 21, 2026 19:01
gr2m added a commit that referenced this pull request May 21, 2026
## Summary

- Backport of #15519 to `release-v6.0`.
- Change `concurrency.group` in `.github/workflows/release.yml` from a
single global `'release'` to `'release-${{ github.ref }}'` so each
release branch (`main`, `release-v6.0`, `release-v5.0`) gets its own
concurrency slot.

## Why

All three Release runs currently share one concurrency group. With
`cancel-in-progress: false`, GitHub queues at most one pending run per
group, so when pushes land on multiple branches within seconds (as today
across #15509, #15513, #15517), the middle pending run gets bumped from
the queue and canceled — e.g. run
[26246209250](https://github.com/vercel/ai/actions/runs/26246209250).

Scoping the group per branch lets each branch's Release workflow run
independently while still serializing within a single branch.

## Test plan

- [ ] Land on `main` (#15519), `release-v6.0`, and `release-v5.0`
- [ ] Verify overlapping pushes across branches no longer cancel each
other
gr2m added a commit that referenced this pull request May 21, 2026
## Summary

- Backport of #15519 to `release-v5.0`.
- Change `concurrency.group` in `.github/workflows/release.yml` from a
single global `'release'` to `'release-${{ github.ref }}'` so each
release branch (`main`, `release-v6.0`, `release-v5.0`) gets its own
concurrency slot.

## Why

All three Release runs currently share one concurrency group. With
`cancel-in-progress: false`, GitHub queues at most one pending run per
group, so when pushes land on multiple branches within seconds (as today
across #15509, #15513, #15517), the middle pending run gets bumped from
the queue and canceled — e.g. run
[26246209250](https://github.com/vercel/ai/actions/runs/26246209250).

Scoping the group per branch lets each branch's Release workflow run
independently while still serializing within a single branch.

## Test plan

- [ ] Land on `main` (#15519), `release-v6.0` (#15520), and
`release-v5.0`
- [ ] Verify overlapping pushes across branches no longer cancel each
other
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

maintenance CI, internal documentation, automations, etc

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant