ci: one verification path per change - #300
Merged
Merged
Conversation
Local gates are where a change is verified before it is pushed; the workflows are the safety net for contributors and the trace check. They were doing three things that only repeated a result already in hand: - a run on every push to main. A squash merge produces exactly the tree of the pull-request tip that just passed, so this rebuilt a known-green tree. Main is now exercised once a night instead, which also catches toolchain and base-image drift between merges, and on demand. - both the old and the new run when a pull request was force-pushed. A concurrency group cancels the superseded one; scheduled runs are never cancelled. - `dist plan` on every pull request (release.yml). It re-parsed the dist manifest, which the tag-triggered pipeline does anyway, and it fired alongside the CI workflow on every update. `pr-run-mode = "skip"` and release.yml regenerated with dist 0.32.0. The static musl archive, the release step that can actually break, is still built by ci.yml on every pull request. Measured before the change: merging nine stacked pull requests fired 48 runs, about 260 runner-minutes, every one on a tree already tested.
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.
The local gates (
make check, the Docker matrix, the deployment suite) are where a change is verified. The workflows are the safety net for contributors and the trace check. They were doing three things that only repeated a result already in hand.No run on every push to main. A squash merge produces exactly the tree of the pull-request tip that just passed, so that run rebuilt a known-green tree. Main is now exercised once a night, which also catches toolchain and base-image drift between merges, and on demand through
workflow_dispatch. The README badge follows the default branch, so it reports the nightly run.A force-push cancels the superseded run. A concurrency group keyed on the pull-request number; scheduled runs are never cancelled.
No
dist planon pull requests. It re-parsed the dist manifest, which the tag-triggered pipeline does anyway, and it fired alongside the CI workflow on every update.pr-run-mode = "skip"indist-workspace.toml, andrelease.ymlregenerated with dist 0.32.0 (the diff is the one removed trigger line). The static musl archive, the release step that can actually break, is still built byci.ymlon every pull request.Measured before the change: merging the nine stacked pull requests #291 to #299 fired 48 runs, about 260 runner-minutes, every one on a tree already tested, and queued behind the rest of the organisation.
Checked with actionlint 1.7.7:
ci.ymlis clean; the remaining findings are pre-existing shellcheck style notes inside the dist-generatedrelease.yml.