Feedback: moving from SHA pins to a lockfile lets Dependabot propose unmerged branches
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 39/100
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 295
- Fork
- 21
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 64
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của github/gh-actions-lock
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
github/gh-actions-lock#271 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
github/gh-actions-lock#272 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
github/gh-actions-lock#268 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 58/100
github/gh-actions-lock#267 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
github/gh-actions-lock#266 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của github/gh-actions-lock
Issue tương tự
-
enhancement needs:sonnet ready-for-agent
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
microsoft/TypeScript#65370 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
docs: data-ownership invites vendors to build add-ons around the OSCó thể đã có người làm @brandli đã nhận hôm nay. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
gentian-org/gentian-os#894 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug tech debt testing
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
aws/amazon-vpc-cni-k8s#3976 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug raised-by:desk
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
medici-finance/assay#5678 ·
Maintainer thường phản hồi trong vòng 1 ngày