Summary
gh aw compile always writes the CLI's bundled firewall/AWF container version into the generated *.lock.yml files, but nothing updates the containers block in .github/aw/actions-lock.json to match. gh aw upgrade/update only re-pin the digests of whatever container versions are already present in actions-lock.json — they never bump that version to the one compile actually emits, and they never prune superseded versions. The result is a repo where the compiled workflows reference one AWF version while actions-lock.json records a different (older) one.
Environment
gh aw version v0.79.8
- Target repo had
actions-lock.json containers pinned at ghcr.io/github/gh-aw-firewall/*:0.27.0 (and, in another repo, accumulated both 0.25.58 and 0.27.0).
Repro
- Clone a repo whose
actions-lock.json containers block pins an older AWF (e.g. 0.27.0).
- Run the standard maintenance sequence:
gh aw upgrade
gh aw update --cool-down 0
gh aw compile
- Inspect the results:
# compiled workflows:
grep -rhoE 'gh-aw-firewall/[a-z-]+:[0-9.]+' .github/workflows/*.lock.yml | sort -u
# -> gh-aw-firewall/agent:0.27.2 (the CLI's bundled version)
# pin cache:
grep -oE 'gh-aw-firewall/[a-z-]+:[0-9.]+' .github/aw/actions-lock.json | sort -u
# -> gh-aw-firewall/agent:0.27.0 (unchanged / stale)
gh aw upgrade logs Pinned 3 container image(s): ...:0.27.0... / Updated container pins in actions-lock.json — i.e. it re-pins the existing 0.27.0 entries rather than the 0.27.2 that compile uses.
Expected
After upgrade/compile, the containers entries in actions-lock.json should match the AWF version that compile writes into the *.lock.yml files (and stale/superseded versions should be pruned), so the two are consistent.
Actual
actions-lock.json containers stays at the old version (and can accumulate multiple old versions). Removing the stale containers block and re-running upgrade/compile does not re-add it at the current version. gh aw compile --force-refresh-action-pins only affects action SHAs, not container pins. So there is no command that reconciles the container pins.
Impact
The compiled workflows run fine (the *.lock.yml files carry the correct inline …:0.27.2@sha256:… digests). But actions-lock.json becomes internally inconsistent with the workflows, which is misleading for — and breaks — any tooling that reads actions-lock.json to pre-fetch/verify container images (it would fetch the stale tags/digests). It also produces noisy "version mismatch" review flags on automated upgrade PRs.
Suggestion
Have gh aw upgrade/compile bump (and prune) the actions-lock.json containers entries to the AWF version the compiler emits, the same way action SHAs are kept current.
Summary
gh aw compilealways writes the CLI's bundled firewall/AWF container version into the generated*.lock.ymlfiles, but nothing updates thecontainersblock in.github/aw/actions-lock.jsonto match.gh aw upgrade/updateonly re-pin the digests of whatever container versions are already present inactions-lock.json— they never bump that version to the onecompileactually emits, and they never prune superseded versions. The result is a repo where the compiled workflows reference one AWF version whileactions-lock.jsonrecords a different (older) one.Environment
gh aw versionv0.79.8actions-lock.jsoncontainerspinned atghcr.io/github/gh-aw-firewall/*:0.27.0(and, in another repo, accumulated both0.25.58and0.27.0).Repro
actions-lock.jsoncontainersblock pins an older AWF (e.g.0.27.0).gh aw upgradelogsPinned 3 container image(s): ...:0.27.0.../Updated container pins in actions-lock.json— i.e. it re-pins the existing0.27.0entries rather than the0.27.2thatcompileuses.Expected
After
upgrade/compile, thecontainersentries inactions-lock.jsonshould match the AWF version thatcompilewrites into the*.lock.ymlfiles (and stale/superseded versions should be pruned), so the two are consistent.Actual
actions-lock.jsoncontainersstays at the old version (and can accumulate multiple old versions). Removing the stalecontainersblock and re-runningupgrade/compiledoes not re-add it at the current version.gh aw compile --force-refresh-action-pinsonly affects action SHAs, not container pins. So there is no command that reconciles the container pins.Impact
The compiled workflows run fine (the
*.lock.ymlfiles carry the correct inline…:0.27.2@sha256:…digests). Butactions-lock.jsonbecomes internally inconsistent with the workflows, which is misleading for — and breaks — any tooling that readsactions-lock.jsonto pre-fetch/verify container images (it would fetch the stale tags/digests). It also produces noisy "version mismatch" review flags on automated upgrade PRs.Suggestion
Have
gh aw upgrade/compilebump (and prune) theactions-lock.jsoncontainersentries to the AWF version the compiler emits, the same way action SHAs are kept current.