Feedback: moving from SHA pins to a lockfile lets Dependabot propose unmerged branches

Aperta
  • Qualcosa non va?
#273 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
39/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, go
Ambito
cli, security

Direzione di ricerca

Start by reading the ref resolution and narrowing behavior in the CLI, especially the path that rewrites SHA pins to tags, and inspect related discussion in #130. The report gives reproducible cases and asks whether to warn or flag version-like branches, but leaves the intended behavior open; clarify the desired outcome before implementation. Done should include a decided behavior and coverage for the reported SHA, tag, and branch cases.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

We tested how Dependabot handles an unmerged branch named like a version. Some of this may belong in dependabot-core, but the outcome changes when a repo moves to a lockfile, and Dependabot regenerates actions.lock through this CLI. Are you aware of it, and should something change?

What we saw

An action repo has a release tag v0.1.0 and an unmerged v1 branch, with no v1 tag. Dependabot's result depends on how the consumer pins the action:

Consumer pin Dependabot
@f95b8e2... # v0.1.0 (SHA on a tagged commit) No PR
@v0.1.0 PR to @v1
@v0.1.0 with actions.lock PR to @v1, lockfile included

Before lockfiles we pinned by SHA. Running gh actions-lock on our SHA consumer rewrote the uses: line and dropped the version comment:

-      - uses: getplumber-examples/print-version-demo@f95b8e245021b29ca2ed35c1f14589a12142b068 # v0.1.0
+      - uses: getplumber-examples/[email protected]

--no-narrow keeps the SHA, as mentioned in #130, but a default run doesn't. So a repo that adopts the lockfile with a default run goes from the first row of the table to the third, and starts getting a proposal it didn't get before. We ran one test of each pin, only with a SHA on a tagged commit, and we didn't run Dependabot on a --no-narrow lockfile.

The Dependabot PR changes the lockfile like this:

-    'getplumber-examples/[email protected]':
-        ref: 'v0.1.0'
-        commit: 'sha1-f95b8e245021b29ca2ed35c1f14589a12142b068'
+    'getplumber-examples/print-version-demo@v1':
+        ref: 'v1'
+        commit: 'sha1-62fd2ca978b7b2e6e61a02583cd70605527f50f0'

gh actions-lock --verify passes on the PR branch, and the PR's run executes the unmerged code. ref: 'v1' looks the same as a major version tag, so a reviewer can't tell from the diff that a branch replaced the release. Branch refs are fine when someone picks them on purpose, like @main. Here the branch only got picked because its name looks like a version.

The lockfile still helped: when v1 moved, the re-run kept the locked commit, while a consumer without a lockfile ran the new code. When v1 was deleted, the runner refused the pin and --verify failed with Ref no longer exists.

We used gh-actions-lock v0.4.0 for the local runs. No Require lockfile policy was set, and --verify ran locally, not in CI.

Questions
  1. Is this known, and is it expected?
  2. Should gh actions-lock warn when it rewrites a SHA pin to a tag, since Dependabot's updates change with it?
  3. Would a finding make sense when a version-like ref resolves to a branch? The CLI already tells tags and branches apart when it resolves a ref.
  4. Or is this only for Dependabot's version selection? If so, I'll open an issue on dependabot-core.
Lingua principale
Go
Stelle
295
Fork
21
Merge medio
1g 3h
PR unite (30g)
64

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di github/gh-actions-lock

Tutte le issue di github/gh-actions-lock

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.