Repository navigation
ci(build): give each push to main its own concurrency group - #14071
Conversation
The push group was build-push-<ref> with cancel-in-progress off. GitHub keeps one waiting run per group, so each push that arrived while a build ran replaced the waiting one. Between 2026-10-30 01:04 and 2026-10-31 13:17, 549 pushes to main started and 512 of those commits never got a completed build, although CONTRIBUTING.md promises a full Linux and Windows build for every push. Group pushes by commit, as boykopovar#13954 does for emscripten-libraries.yml and input-mapper.yml, so every push runs. Pull requests and manual runs keep their groups.
Check that build.yml groups each push by commit and that a later push never cancels an earlier one. Without the first check the group falls back to the branch and a waiting push is replaced by the next.
BunnyFl
left a comment
BunnyFl
left a comment
There was a problem hiding this comment.
Looks right to me. main still has build-${{ github.event_name }}-${{ … || github.ref }} with cancel-in-progress off for pushes. GitHub keeps one pending run per group, so a third push replaces the second's waiting run and that commit never builds. Keying push runs on github.sha gives each commit its own group. Pull requests (pull_request.number) and manual runs (inputs.pr, then ref) keep their groups, and since && returns github.sha only for a push, the fallback order is unchanged for every other event.
Tested on Windows 11, Python 3.14, with head e4184fd518 merged onto current main: tools/tests/test_build_eligibility.py passes 12 tests. With build.yml put back to main's version, test_each_push_to_main_has_its_own_concurrency_group fails.
The trade-off you name, more concurrent push builds on the self-hosted Linux runners, is the maintainer's call, but it's what CONTRIBUTING's "every push" promise needs.
|
Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.
|
What
The push group of
build.ymlwasbuild-push-<ref>withcancel-in-progressoff. GitHub keeps one waiting run per group, so a push that arrived while a build ran replaced the waiting one. Between 2026-10-30 01:04 and 2026-10-31 13:17 (the last 1000 build runs), 549 pushes tomainstarted and 512 of those commits never got a completed build. CONTRIBUTING.md promises a full Linux and Windows build for every push.This groups push runs by commit, as #13954 does for
emscripten-libraries.ymlandinput-mapper.yml, so every push runs. Pull requests and manual runs keep their groups, andcancel-in-progressstays off for pushes.Commits:
ci(build): the group expression gains(github.event_name == 'push' && github.sha)before the branch fallback (one line).test(tools): two text checks intools/tests/test_build_eligibility.pypin the push group andcancel-in-progress.Trade-off: a burst of pushes now runs more builds at once. The Linux jobs run on self-hosted runners.
The write-watch check fails on main until #13220 merges:
core/libs/tests/write_watch/CMakeLists.txtregisters two test names twice, so the macOS write-watch configure stops. This PR does not change that file.Tested
Linux, Python 3.11.2, Node v20.19.2, on
upstream/main0f302813ce:python3 tools/tests/test_build_eligibility.py: 12 tests, OK (the two new tests included).build.ymlrestored fromupstream/mainwith the new tests in place failstest_each_push_to_main_has_its_own_concurrency_groupwith"(github.event_name == 'push' && github.sha)" not found.python3 tools/check_conventions.py --base upstream/main: all conventions checks passed.git diff --check upstream/main: clean.build.ymlparses as YAML and the group expression is as written.tools/pr_overlap.py --branch ci/push-builds-per-commit: no overlap with open pull requests.Not run: hosted GitHub Actions. The group only takes effect on real push events, so the behaviour on
mainis verified by reading GitHub's concurrency rules, not by a run. The C++ build and CTest (no C++ changed).Checklist
main; no other open PR implements the same functionsNotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file.mdfiles or images added to the repository (attach them to this PR)