also looking at this
ci: pin the pantry action to a commit
#45
7 files
+35
-15
| @@ -11,3 +11,23 @@ This folder contains the following GitHub Actions: | ||
| 11 | 11 | |
| 12 | 12 | [CI]: ./workflows/ci.yml |
| 13 | 13 | [Release]: ./workflows/release.yml |
| 14 | ||
| 15 | ## Pinned actions | |
| 16 | ||
| 17 | `pantry-pm/pantry/packages/action` is pinned to a commit, not to `@main`. | |
| 18 | ||
| 19 | `@main` means an unrelated push to another repository decides whether every | |
| 20 | job here runs, and on 2026-08-20 that happened twice in one night: first the | |
| 21 | action stopped shipping its built `dist/index.js`, so every job failed at step | |
| 22 | one with `File not found`; then, after that was fixed upstream, the setup step | |
| 23 | began hanging — every job on both Linux and macOS sat on **Setup Pantry** until | |
| 24 | GitHub killed it at the six-hour ceiling. | |
| 25 | ||
| 26 | The pin is `ef37fca8440cdb483fb355fefa5ae3cc6e669a69` (pantry 0.11.36), the | |
| 27 | revision the last fully green run on `main` used. | |
| 28 | ||
| 29 | To bump it: change the SHA everywhere it appears under `.github/workflows/`, | |
| 30 | in one commit, and let CI prove the new revision before it lands. The same | |
| 31 | reasoning applies to the first-party Zig dependencies — see | |
| 32 | [`.github/actions/first-party-zig-deps/pins.env`](../actions/first-party-zig-deps/pins.env). | |
| 33 | ||