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

Đang mở
#273 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, go
Lĩnh vực
cli, security

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.

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.
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

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của github/gh-actions-lock

Tất cả issue của github/gh-actions-lock

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.