Plain run drops a transitive `uses` edge when the transitive dependency is also used directly by the workflow (v0.4.1)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 68/100
Direzione di ricerca
Start by tracing the plain-run lockfile generation path and how composite-action dependencies are merged when an action is also used directly; the payload does not name source files or tests. Reproduce with the supplied workflow scenario and compare the generated entry with --relock. Done when the composite action records both nested uses edges and --verify passes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What happened
When a composite action is bumped and actions.lock is regenerated with a plain run (no --relock), the new entry for the composite action is missing one of its nested dependencies. That nested dependency is also used directly in the same workflow. Afterwards, gh actions-lock --verify fails:
✗ Lockfile doesn't match locked manifest dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061
dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5 at locked commit b4b0d3fccf24 uses dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061, but its lockfile entry dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5 does not record it
! restore the edge from version control, or run `gh actions-lock --relock`
↳ .github/workflows/deploy-hato-bot.yml
This looks like #257, which was closed as fixed in v0.4.1. I can still reproduce this case on v0.4.1. The difference here is that the dropped dependency is also a direct dependency of the workflow. Because of that, its top-level dependencies entry stays, and only the uses edge under the composite action is lost.
- Renovate PR: https://github.com/dev-hato/hato-bot/pull/7362 (Renovate 44.220.0, which pins gh-actions-lock v0.4.1)
- Failing verify run: https://github.com/dev-hato/hato-bot/actions/runs/42128781058/job/127599721187
Setup
dev-hato/actions-update-dockle is a composite action. At both the old and the new version, its action.yml uses:
actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061
.github/workflows/deploy-hato-bot.yml uses dev-hato/actions-update-dockle and also uses dev-hato/actions-diff-pr-management@a3c6f1d… directly.
Steps to reproduce
git clone https://github.com/dev-hato/hato-bot && cd hato-bot
git checkout c7022af77510eec4f8c14ea8b120293af11c7760
gh extension install github/gh-actions-lock --pin v0.4.1 --force
# bump the composite action (v0.0.149 -> v0.0.151)
perl -pi -e 's|dev-hato/actions-update-dockle\@[0-9a-f]+ # v[0-9.]+|dev-hato/actions-update-dockle\@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5 # v0.0.151|' \
.github/workflows/deploy-hato-bot.yml
# same invocation Renovate uses
gh actions-lock --no-interactive --no-onboard --no-narrow --ignore-local-actions
gh actions-lock --verify --no-narrow # fails
The resulting diff of actions.lock:
- 'dev-hato/actions-update-dockle@5538777ee98aa1b8016df625c17c6cbe25531f39':
- ref: 'v0.0.149'
- commit: 'sha1-5538777ee98aa1b8016df625c17c6cbe25531f39'
+ 'dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5':
+ ref: 'v0.0.151'
+ commit: 'sha1-b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5'
owner_id: 68012105
repo_id: 517688930
uses:
- 'actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3'
- - 'dev-hato/actions-diff-pr-management@a3c6f1d6cb3f46d2f48ac3856ef603ef2e508061'
The plan output lists only one transitive dependency for the bumped action:
Pinned 1 action (+ 1 transitive) across 1 workflow
dev-hato/actions-update-dockle@b4b0d3f
└─ .github/workflows/deploy-hato-bot.yml
Transitive dependencies (from composite actions):
actions/github-script@3a2844b via dev-hato/actions-update-dockle@b4b0d3fccf24fc77325c624f52a1a1bc9aa6d4b5
Expected behavior
The new entry for dev-hato/actions-update-dockle@b4b0d3f… should record both nested dependencies, including dev-hato/actions-diff-pr-management@a3c6f1d…, even though that action is already locked as a direct dependency of the workflow. --verify should then pass.
Current workaround
gh actions-lock --relock
This restores the missing edge, and --verify passes. But Renovate and Dependabot run plain mode, so every update PR for this action needs a manual relock.
Versions
- gh-actions-lock v0.4.1 (local, CI verify, and Renovate)
- Renovate 44.220.0
Related: #257
- Lingua principale
- Go
- Stelle
- 295
- Fork
- 21
- Merge medio
- 1g 3h
- PR unite (30g)
- 64
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di github/gh-actions-lock
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
github/gh-actions-lock#271 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
github/gh-actions-lock#268 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
github/gh-actions-lock#267 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
github/gh-actions-lock#266 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
github/gh-actions-lock#264 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di github/gh-actions-lock
Issue simili
-
csp-probe needs efqdn to probe CSP domainsForse già presa @unknownhackerworld l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
projectdiscovery/httpx#2725 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
category:helper tech-debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
LanternOps/breeze#11285 ·
I maintainer di solito rispondono entro 1 giorno
-
Query cache: a failed cache page read leaves the set request's read lock held, so the scan hangsAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
turbot/steampipe-plugin-sdk#986 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100