ci: float the first-party reusables on main so they stop freezing - #14
Open
forkwright wants to merge 1 commit into
Open
ci: float the first-party reusables on main so they stop freezing#14forkwright wants to merge 1 commit into
forkwright wants to merge 1 commit into
Conversation
A SHA pin on forkwright/.github cannot be maintained. That repo publishes no tags, so dependabot has no version to compare a SHA against and never touches the line -- the pin does not stay reviewed, it freezes. This is measured rather than theoretical. akroasis sat on a revision predating a fix to the very workflow it called while its own comment asserted dependabot maintained it. typikon's gate failed on a defect already fixed upstream that its pin could not reach; floating it turned the gate green, which is the evidence this change rests on. Across the fleet the same reusable was pinned at three different SHAs in three repos, the oldest seven weeks behind. Where a rationale comment existed it is answered rather than deleted. The concern it raised -- that a mutable ref can change behaviour under an already-merged commit -- is real. But the mitigation it proposed was a manual refresh procedure, and nobody ran it. A first-party reusable holding none of our secrets is not the supply-chain case a SHA pin exists for, and the ci-substrate SPEC settles the convention: triggers, permissions and inputs live in the caller, logic is delegated, pin @main. A floating first-party ref cannot go stale, which is stronger than any process for keeping it fresh. Third-party pins are untouched. Those are the genuine supply-chain case, dependabot does maintain them, and they stay on a SHA.
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.
Finding
A SHA pin on
forkwright/.githubcannot be maintained. That repo publishes no tags, so dependabot has no version to compare a SHA against and never touches the line. The pin does not stay reviewed — it freezes.Measured, not theoretical
Where a rationale existed, it is answered rather than deleted
Several repos stated a deliberate reason for SHA-pinning: a mutable ref lets the remote workflow change under an already-merged commit. That concern is real, and it is the actual tradeoff.
But the mitigation each one proposed was a manual refresh —
gh api repos/forkwright/.github/commits/main, review the diff, bump. Nobody ran it. So the pin did not stay reviewed; it went stale, in one case far enough that the gate began failing on something already fixed.A first-party reusable holding none of our secrets is not the supply-chain case a SHA pin exists for. The ci-substrate SPEC settles the convention — "Triggers + permissions + inputs live in the caller; logic is delegated. Pin
@main." A floating first-party ref cannot go stale, which is a stronger property than any process for keeping it fresh.What is not changed
Third-party pins are untouched.
actions/checkout,Swatinem/rust-cacheand the rest stay SHA-pinned — those are the genuine supply-chain case, dependabot does maintain them, and OpenSSF Scorecard asks for exactly that.Only the
uses:ref and its comment changed. Nowith:orsecrets:block was modified, so the call itself is identical to before.Verified
Every referenced workflow —
hybrid-gate,gate-attestation,release-please,dependabot-auto-merge,stale,codeql,security— was confirmed to exist onforkwright/.github@mainbefore floating. Nothing was floated blind at a renamed or removed target. All touched files parse as valid YAML.Part of a fleet-wide pass across eleven repos.