Skip to content

EPBDS-16211: every master commit gets a CI run of its own - #217

Merged
AlexSamBY merged 1 commit into
masterfrom
master-ci-runs
Oct 13, 2026
Merged

AlexSamBY merged 1 commit into
masterfrom
master-ci-runs

Conversation

@AlexSamBY

@AlexSamBY AlexSamBY commented Oct 13, 2026 •

Copy link
Copy Markdown
Member

What

Each push to master gets a CI run of its own. A push to master now has a concurrency group named by its commit (github.sha). A pull request's group is still its ref, and its newer push still cancels the run before it.

Why #205 was not enough

#205 stopped a push to master from cancelling the run in progress: cancel-in-progress is on for pull requests only. But a group still holds at most one running run and one pending run. GitHub cancels the pending one when another is queued, whatever cancel-in-progress says. From GitHub's documentation: "any existing pending job or workflow in the same concurrency group will be canceled".

It happened on 2026-10-12, when #214, #215 and #216 merged within two minutes:

commit its run was created what happened to it
1b16e4d (#214) 16:12:35 ran until 16:18:20, success
5cb6bf6 (#215) 16:13:29 pending behind it; cancelled at 16:14:02 with no job started
1710577 (#216) 16:14:01 success

5cb6bf6 is the case #205 set out to prevent: a master commit with no finished run.

The change

  • .github/workflows/ci.yml: the group is ci-${{ github.workflow }}-${{ github.event_name == 'push' && github.sha || github.ref }}. Master's runs no longer share a group, so none waits and none is cancelled; merges in quick succession run in parallel. The comment says why one group for the branch was not enough.
  • Why not queue: max: it keeps up to 100 pending runs per group, but GitHub's documentation says it cannot be combined with cancel-in-progress: true, which pull requests use.
  • The changelog: its entry said "CI cancels a run only when a newer push to the same pull request supersedes it". It now says that each master commit gets a run of its own.

The same fix for release/v0.34's ci-0.34.yml is #218.

Verified

  • The workflow parses (js-yaml).
  • For a push, the group comes out as ci-CI-<sha>; for a pull request, as ci-CI-refs/pull/<n>/merge. && and || return one of their operands, the common way to pick a value in a workflow expression. This PR's own run evaluates the expression, so a syntax error would have kept it from starting.
  • This PR's own run uses the pull-request group, which is unchanged. The push groups show on the next merges in quick succession: each commit should get a finished run.

Gates

All 22 gates and the manifest contract exit 0 on HEAD, on Node 24.14.0.

🤖 Generated with Claude Code

A concurrency group holds one running run and one pending one, and GitHub cancels the pending run when
another arrives, whatever `cancel-in-progress` says. #205 stopped a push to master from cancelling the run in
progress, but with one group for the branch the run waiting behind it was still dropped. On 2026-10-12 three
PRs merged within two minutes, and 5cb6bf6 (#215) got no run. Each push to master now has a group named by its
commit. A pull request's newer push still supersedes its run.

The changelog said that CI cancels a run only for a newer push to the same pull request; it now says what CI
does.
@AlexSamBY
AlexSamBY merged commit d265c01 into master Oct 13, 2026
8 checks passed
@AlexSamBY
AlexSamBY deleted the master-ci-runs branch October 13, 2026 09:14
AlexSamBY added a commit that referenced this pull request Oct 13, 2026
## What

Each push to release/v0.34 gets a CI run of its own. A push to the
branch now has a concurrency group named by its commit (`github.sha`),
as master's does with #217. A pull request's group is still its ref, and
its newer push still cancels the run before it.

## Why

A group holds at most one running run and one pending run, and GitHub
cancels the pending one when another is queued, whatever
`cancel-in-progress` says ([GitHub's
documentation](https://docs.github.com/en/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency)).
With one group for the branch, a push whose run was waiting behind
another's lost that run when a third push arrived. Master's CI lost
5cb6bf6's run that way on 2026-10-12, when three PRs merged within two
minutes. The workflow's comment said "A push to the branch keeps its
run"; it now says how.

## Verified

- Only `.github/workflows/ci-0.34.yml` changes; no code does. The
workflow parses (js-yaml).
- This PR's own run checks the workflow on the pull-request path, which
is unchanged.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant