From 0dc7b192e198584a57731478f9c3a3218a7ab60e Mon Sep 17 00:00:00 2001 From: hyperpolymath <6759885+hyperpolymath@users.noreply.github.com> Date: Sun, 31 May 2026 00:23:52 +0100 Subject: [PATCH] =?UTF-8?q?ci(rust-ci):=20bump=20reusable=20pin=20cc5a372a?= =?UTF-8?q?=20=E2=86=92=20822fa14e=20(estate-wide=200s=20parse=20failure)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit panic-attack rust-ci.yml + 42 other estate repos that pin rust-ci-reusable.yml@cc5a372a have been failing with 0s-duration "workflow file issue" parse errors since 2026-05-26 (when PR #45 introduced the thin-wrapper). cc5a372a IS reachable from standards/main (verified via git merge-base --is-ancestor), so this is NOT the orphan-SHA failure mode panic-attack#84 thought it was fixing. Empirical: every recent rust-ci run failed at parse time. The reusable's content at cc5a372a is structurally fine. The simplest hypothesis is that GH Actions has cached a bad resolution of this specific SHA — repinning to a fresher merge-commit forces re-fetch. 822fa14e is the current HEAD of standards/main on the file (standards#299, "pass --locked to cargo check/clippy/test"). Bumping forward to that brings the --locked safety along with the unblock. If 822fa14e also fails parse: the issue is not the SHA, and the caller-side workflow file needs investigation (the workflow's API-reported name field has been ".github/workflows/rust-ci.yml" not "Rust CI", suggesting GH never parsed it successfully). Co-Authored-By: Claude Opus 4.7 (1M context) --- .github/workflows/rust-ci.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/rust-ci.yml b/.github/workflows/rust-ci.yml index 1b1b792..015b2ae 100644 --- a/.github/workflows/rust-ci.yml +++ b/.github/workflows/rust-ci.yml @@ -14,4 +14,4 @@ permissions: jobs: rust-ci: - uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@cc5a372af1af1b202c17f1b21efd954e6c038bef + uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@822fa14e2a4b7a93c40677e12d2d060e83b95776