Repository navigation
fix(ci): merge the lockfile, never rebuild it — restores the lockfile blocks that broke Pages - #243
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Caution Review failedThe pull request is closed. 📝 Summary
Merge Risk:
|
Merging #242 took the Pages deploy on `main` down: `casket-pages` concluded `failure` in **Set up job**, with one annotation — lockfile missing pin for actions/upload-artifact@bbbca2d Same workflow, same pins, same commit as before: the only thing that changed was `actions.lock`. `pin-workflow-uses.py` rebuilt the `dependencies:` section from the `uses:` lines it could see, so it deleted (a) the action that `actions/upload-pages-artifact` resolves for itself at run time and (b) every tag-keyed alias block `gh actions-lock` had written. GitHub validates the lockfile at job setup, so the workflow died before its first step and the message named an action no file of ours mentions. Regeneration now MERGES into the committed `dependencies:` blocks: existing entries are preserved verbatim (their `ref`, `commit`, `owner_id`, `repo_id` and `uses:` lists), and only missing keys are added, inheriting identity from the blocks already there. `--check` is idempotent over the merged form, so CI detects drift without being the thing that destroys the file. The blocks the earlier regeneration removed are restored. Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
5eefde8 to
4b83c40
Compare
…ile entry (#244) Follow-up to #243. Restoring the deleted lockfile blocks was necessary and **not sufficient**: Pages still failed in `Set up job` with the same annotation. The dependency list lives on the wrong entry after a re-pin: ```yaml 'actions/upload-pages-artifact@v5.0.0': # gh actions-lock wrote `uses:` here uses: - 'actions/upload-artifact@bbbca2dd…' 'actions/upload-pages-artifact@fc324d35…': # the workflow names THIS one ref: 'v5.0.0' # no `uses:` — so GitHub found no dependency list and refused the job ``` Regeneration now copies the `uses:` list onto every entry describing the same commit, so re-pinning an action can never separate it from the actions it resolves at run time. Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
What this fixes
Merging #242 (
df96e43) took the Pages deploy onmaindown.casket-pagesconcluded
failurein Set up job — no step ran — with a single annotation:Same workflow, same pins, same repository as the run that passed 12 hours earlier
on
b5530834. The only difference was.github/workflows/actions.lock.Why
scripts/ci/pin-workflow-uses.pyrebuilt the lockfile'sdependencies:sectionfrom the
uses:lines it could see in this repository's workflows. That deletestwo things the file legitimately contains and cannot be re-derived from a grep:
actions/upload-pages-artifactrunsactions/upload-artifact@bbbca2dd…itself, and no file of ours mentions it;
actions/checkout@v7.0.1→ the SHA) thatgh actions-lockwrites alongside each SHA entry.GitHub validates the lockfile at job setup, so the deletion surfaces as a job
that never starts and a name nothing in the tree contains.
The change
dependencies:blocks: existingentries are preserved verbatim (
ref,commit,owner_id,repo_id,uses:), and only missing keys are added, inheriting identity from the blocksalready present.
--check— what CI runs — is idempotent over the merged form,so it detects drift without being the thing that destroys the file.
docs/CI-CD.adocrecords the rule, so the next person to "tidy" the lockfilefinds it written down rather than by taking CI down.
One annotation was the whole failure. It is in this PR's description because the
next one of these will be too.