fix(ci): regenerate actions.lock — workflow refs had drifted ahead of it - #49
Conversation
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>
|
|
Note Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime. Code Review ✅ ApprovedRegenerated the actions.lock file to align with updated workflow action references, resolving the lockfile enforcement check failure. No issues found.
OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Important Your trial ends in 3 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more. Was this helpful? React with 👍 / 👎 | Gitar |
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
1 participant
Workflows reference action versions this lockfile does not pin. Actions were
bumped in the workflows and
gh actions-lockwas never re-run, so the lockfilestill 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. Everyentry 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 ofworkflows:, which made the whole fileunparseable 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; andgh actions-lock --no-fixpasses 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