Feedback: moving from SHA pins to a lockfile lets Dependabot propose unmerged branches
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 39/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Action repo PR, never merged: https://github.com/getplumber-examples/print-version-demo/pull/2
- Full write-up: https://github.com/getplumber-examples/github-actions-miscellaneous-knowledge/tree/test/2026-11-06-dependabot-unmerged-branches
Questions
- Is this known, and is it expected?
- Should
gh actions-lockwarn when it rewrites a SHA pin to a tag, since Dependabot's updates change with it? - 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.
- Or is this only for Dependabot's version selection? If so, I'll open an issue on dependabot-core.
- Lenguaje dominante
- Go
- Estrellas
- 295
- Forks
- 21
- Merge medio
- 1 d 3 h
- PR fusionados (30 d)
- 64
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de github/gh-actions-lock
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
github/gh-actions-lock#271 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
github/gh-actions-lock#272 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
github/gh-actions-lock#268 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
github/gh-actions-lock#267 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
github/gh-actions-lock#266 · 1 reacción ·
Los mantenedores suelen responder en 1 día
Todos los issues de github/gh-actions-lock
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
adrianbrad/queue#92 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
agent-ready area:skills
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
jmbarzee/temporal-architect#444 ·
Los mantenedores suelen responder en 1 día
-
enhancement needs:sonnet ready-for-agent
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día