ci: run the release's Linux gate alongside the other platforms - #240
Merged
Merged
Conversation
- Gate every platform in one parallel job and leave the publishing job to build and publish, so the Linux gate no longer waits behind the slowest platform leg - Run the gate command CI runs, and redden CI when the two differ - Assert that the publishing job needs the gate job, in place of the line-order check that assumed both sat in one job
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
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.
The release workflow ran its Windows and macOS gates first and its Linux gate afterwards, inside the publishing job, so every release waited for the slowest platform leg and then for the whole Linux gate on top. This change runs all three gates in parallel in one
gatejob and leaves the publishing job to install, build and publish, withneeds: [changes, gate]. The gate step is CI's own line,npm run checkon Linux andnpm run check:platformelsewhere, and CI now reddens if the two workflows' gate commands differ.What it costs
The publishing job no longer publishes the very build that was gated. It rebuilds the same commit from the same lockfile on a fresh runner, so the guarantee becomes "this commit passed the gate" rather than "these files passed it". Handing the gated build over as an artifact would not restore the stronger form anyway, because
release.mjsstamps the version into the tree after the gate. In exchange, the one job holdingid-token: writenow runs only the install, the build and the publish, not the whole test suite.Times
From the first release run under the layout this replaces (run 36698204577, today):
Under this change the Linux gate runs next to Windows and finishes first: roughly 5 minutes, estimated from the same steps. Start to publish then becomes the Windows leg plus the publishing job's 1 m 17 s, about 8 m 20 s, which saves the 3 m 35 s the Linux gate took. That figure is an estimate from one run, not a measurement of the new layout.
How I know it works
As with the previous change to this file, the new jobs cannot run before merge: CI does not execute
release.yml, and dispatching it would publish. The evidence is CI's guard step, run locally against mutated copies ofrelease.yml. Each mutation reddens it with the message it should:gatedropped from the publishing job'sneeds:: "publishing job 'release' does not need the gate job".needs:line moved off the publishing job onto another job: the same message. Finding the line anywhere in the file is not enough.npm run check:platformon every leg: fails, printing both commands.<no Full gate step>.os:list: the environment comparison fails, naming both lists.The guard reads the gate command out of both files rather than spelling it: Actions expands a
${{ … }}inside arun:script before bash sees it, so a literal copy of the line would have been compared asnpm run check.Follows #237, which gave the release gate its Windows and macOS legs.