ci: float the first-party reusables on main so they stop freezing - #16
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.
Correction — merge-order conflict with #20#20 fully rewrites Whichever of #16/#20 merges second will conflict on Full detail on #20. Not actioned directly — no merge authority exercised here and no push to this branch without the release-please.yml intent confirmed. |
1 participant
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.