Locking a major tag fails on every release of actions that release each version from its own branch (every azure/* action checked)

Đang mở
  • Có gì không ổn?
#280 0 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
25/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cli, github-actions, go
Lĩnh vực
cli, devtools

Hướng nghiên cứu

The issue is a design question about how the lock check compares a pinned commit to the current history of a major tag, and the payload names no specific file or function. Start by reading the lock verification path in the Go CLI and the behaviour referenced in #202 and #174. The issue is not a clear first task: it asks for a choice among three designs, and a maintainer decision is needed before any patch. Done means that decision is recorded and the chosen approach is covered by tests.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

A workflow uses azure/setup-helm@v5, locked to 9bc31f4 (v5.0.1). When v5.1.0 shipped and v5 moved to 2f5e7bc, every run failed with:

Lockfile pin 9bc31f4… for `azure/setup-helm` does not match ref `v5`. Ensure the pinned commit exists on the expected branch or tag.

Nothing in our repository changed, and the locked commit still exists in azure/setup-helm. An upstream's release process broke our runs, and that's what a lockfile is supposed to protect against. For a reusable workflow it breaks every consumer at once, until the owner relocks and releases.

How the locked commit left v5's history

Nothing was deleted or force-pushed. azure/setup-helm makes each release as a separate build commit (the compiled action) on top of a main commit, on a release branch that is never merged back:

main:   95ecf49 "bump 5.0.1" ── … ── 206711c "prepare v5.1.0"
            │                              │
            9bc31f4 "build"                2f5e7bc "build"
            = v5.0.1                       = v5.1.0 = v5 (now)

While v5 pointed at 9bc31f4, that commit was in v5's history. After v5 moved, it isn't (compare: diverged, 24 ahead / 1 behind). Per #202, the runner accepts a locked commit when the tag moves forward past it. It only fails when the tag moves to a commit that doesn't contain it, which this release process does on every release.

It's a release pattern, not one repository

For 25 popular actions, I took up to the last 6 releases in the current major and checked whether each release's commit is in the history of the major tag's current commit (GitHub compare API, 2026-11-09). If it isn't, a lock taken while the major tag pointed at that release would fail today.

Action Major Releases that would fail
azure/setup-helm v5 v5.0.0, v5.0.1
azure/login v3 v3.0.0, v3.0.1, v3.0.2
azure/setup-kubectl v5 v5.0.0, v5.1.0
azure/k8s-set-context v5 v5.0.0, v5.0.1
azure/k8s-deploy v7 v7.0.0

None would fail for: aws-actions/configure-aws-credentials, aws-actions/amazon-ecr-login, hashicorp/setup-terraform, github/codeql-action, docker/login-action, docker/metadata-action, docker/setup-qemu-action, golangci/golangci-lint-action, peter-evans/create-pull-request, softprops/action-gh-release, codecov/codecov-action, dorny/paths-filter, JamesIves/github-pages-deploy-action, gradle/actions, actions/github-script, actions/setup-python, actions/setup-go, googleapis/release-please-action.

So whether a major-tag lock survives depends on how each upstream releases, which the workflow author can't see or control.

Expected model

Package managers with lockfiles (Bundler, npm, Cargo) record the exact version the range resolved to (~> 5.0 → 5.0.1) and never check the range again: a 5.1.0 release cannot affect an existing lock. The Actions lockfile records ref: v5 and checks the locked commit against wherever v5 points at each run, so a new upstream release can still break a run that's already locked.

The repository check (owner_id/repo_id) and the protection against fork-only commits (#174) both make sense. But once a major tag has been resolved and locked, requiring the commit to still be in that tag's current history ties the pin back to a tag that moves.

Would you consider one of these?

  • Accept the locked commit if it was in the ref's history when locked, or is in the history of any tag or branch in the action's own repository.
  • Have gh actions-lock record the exact version tag that matched (v5.0.1) alongside the major tag and check against that. This is the Bundler model.
  • At minimum, document that locking a major tag can fail when an upstream releases from separate branches, and recommend exact version tags.
Ngôn ngữ chính
Go
Star
317
Fork
24
Merge trung bình
1 ngày 8 giờ
Pull request đã merge (30 ngày)
50

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.