ci: pull requests only, and the Windows lanes stop building one project at a time - #75
Merged
Merged
Conversation
…ct at a time Three one-line changes, each measured on this repository's own runs rather than assumed. PULL REQUESTS ONLY. The triggers were `push: ['**']` and `pull_request` together, so a branch with a PR open bought TWO complete runs of all five jobs for one commit, and a branch without one bought a run nobody was going to read. In the last sixty runs that is 37 push events against 21 pull_request ones. The pull_request event already covers every branch, and covers it merged into main, which is the stricter object. A concurrency group now also cancels a superseded run instead of letting it finish against code nobody will merge. THE WINDOWS LANES HAD NO PARALLELISM AT ALL. `cmake -B build` with no -G picks the Visual Studio generator here, so `cmake --build` is MSBuild, and MSBuild without /m builds one project at a time. The Linux lanes have asked for -j4 all along and there is a comment beside them explaining why; these two never did. It shows: app-windows spent 14.0 minutes in Build the app, against 3.8 for the same build on Linux, while its whole test phase is 0.3 minutes. A run is 49 machine-minutes and 45 of them are compiling. AND THE BARE -j in core-linux, which means unlimited rather than "use the cores" — harmless in a job that takes 42 seconds, but it is the same footgun the comment beside the Linux lanes already warns about, and leaving one copy of it contradicts the warning.
ci.yml had no `permissions` block, so its token arrived with whatever the repository default grants. The file checks out, builds and uploads artifacts; it never writes to the repository, so `contents: read` says exactly that. This is the one thing CodeQL has ever found in this family — in orbitcab, about a workflow file, not about any code. Timeouts were already on every job here, at 30 and 60 where somebody sized them deliberately. Nothing to add: the earlier count that said otherwise was counting `on:` sub-keys as jobs.
tsyma
force-pushed
the
ci/pr-only-and-parallel
branch
from
September 15, 2026 20:07
bcd74ce to
7608f9e
Compare
release.yml had the same two shapes ci.yml did and they were missed the first time: a bare `-j`, which means unlimited rather than "use the cores", and a Windows build with no parallelism flag at all, which under the Visual Studio generator is MSBuild without /m — one project at a time. The lane that ships is the one where a slow build costs the most attention.
The group I wrote was `ci-<pr number>`, the same literal in every file of a repository. In namz, which
has three workflows, that put ci, js and python in ONE group with cancel-in-progress — so starting js
CANCELLED the other two, and the pull request showed nine cancelled jobs that had done nothing wrong.
Adding ${{ github.workflow }} makes the group what it was meant to be: one live run per workflow per
branch, and workflows that do not race each other.
Caught by looking at the runs after opening the pull requests rather than by reading the diff again,
which is the only reason it surfaced at all: the file looked right in every single repository.
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.
Three one-line changes, each measured on this repository's own runs.
Pull requests only. The triggers were
push: ['**']andpull_requesttogether, so a branch with a PR open bought two complete runs of all five jobs for one commit, and a branch without one bought a run nobody was going to read. In the last sixty runs that is 37 push events against 21 pull_request ones. Thepull_requestevent already covers every branch, and covers it merged into main. Aconcurrencygroup now also cancels a superseded run instead of letting it finish against code nobody will merge.The Windows lanes had no parallelism at all.
cmake -B buildwith no-Gpicks the Visual Studio generator here, socmake --buildis MSBuild, and MSBuild without/mbuilds one project at a time. The Linux lanes have asked for-j4all along, with a comment beside them explaining why; these two never did. It shows:app-windowsrelease-base-linux-j4app-windowsA run is 49 machine-minutes and 45 of them are compiling.
And the bare
-jincore-linux, which means unlimited rather than "use the cores" — harmless in a job that takes 42 seconds, but it is the same footgun the comment beside the Linux lanes already warns about, and leaving one copy of it contradicts the warning.The magnitude of the Windows saving is not promised: MSBuild's
/mparallelises across projects, and a JUCE target is largely one project, so the win could be small. This PR's own run measures it.