Commit 0130819
fix(ci): regenerate actions.lock — workflow refs had drifted ahead of it (#108)
Workflows reference action versions this lockfile does not pin. Actions
were
bumped in the workflows and `gh actions-lock` was never re-run, so the
lockfile
still records the older ref — and lockfile enforcement rejects a
workflow whose
refs it cannot resolve, before any job starts.
Regenerated with `gh actions-lock` (v0.1.6) rather than hand-edited.
Every
entry needs a resolved commit SHA plus owner_id and repo_id, and
hand-authoring
those is exactly how the sibling defect happened — a caller entry
written into
the `dependencies:` map instead of `workflows:`, which made the whole
file
unparseable and killed every workflow in the repo at once.
Verified before pushing, three ways: the hand-authored reusable-caller
entries
survive the regeneration (checked by count, because the tool does not
generate
them and deleting them would re-break the repo); every key under
`dependencies:` still matches owner/repo@ref; and `gh actions-lock
--no-fix`
passes its own verification afterwards.
One of 26 repos of 52 carrying a lockfile — half the estate — found by
scanning
after metadatastician/688-attack-hub#18.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>1 parent 24bf669 commit 0130819
1 file changed
Lines changed: 4 additions & 4 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
5 | 5 | | |
6 | 6 | | |
7 | 7 | | |
8 | | - | |
| 8 | + | |
9 | 9 | | |
10 | 10 | | |
11 | 11 | | |
| |||
47 | 47 | | |
48 | 48 | | |
49 | 49 | | |
50 | | - | |
51 | | - | |
52 | | - | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
53 | 53 | | |
54 | 54 | | |
55 | 55 | | |
| |||
0 commit comments