Lockfile Actions đã GA: dấu kiểm xanh chứng minh điều gì?

Dev
Lượt xem 2

PR có thể giữ nguyên phiên bản uses nhưng mã phía sau đã đổi. Tag có thể trỏ sang commit khác. GitHub công bố lockfile cho workflow được cung cấp rộng rãi ngày 28 tháng 10. Sau giai đoạn xem trước, điều cần hiểu là mỗi phép kiểm tra đưa ra bằng chứng gì.

Tham chiếu dễ đọc, commit được ghi cố định

.github/workflows/actions.lock nối tham chiếu action với commit sẽ chạy. Tệp được tạo bằng gh actions-lock, có trên Free, Team và GitHub Enterprise Cloud kể cả môi trường lưu trú dữ liệu. Có thể đưa từng workflow vào áp dụng. Hãy xem tệp được tạo cùng thay đổi workflow, thay vì tự ráp lockfile bằng tay.

Trong ví dụ giả định, demo/build@v1 ban đầu trỏ A rồi chuyển sang B. Chỉ phân giải tham chiếu có thể chọn mã khác ở lần chạy sau; lockfile chọn commit đã ghi. Hình minh họa không phải thử nghiệm thực tế. Commit không còn truy cập được từ tag hoặc nhánh upstream đã ghi có thể bị từ chối khi chạy.

Ví dụ giả định tự dựng: v1 dịch chuyển và commit đã ghi. Không phải ảnh chạy Actions thực tế.
Ví dụ giả định tự dựng: v1 dịch chuyển và commit đã ghi. Không phải ảnh chạy Actions thực tế.

Kiểm tra ngoại tuyến xác nhận đến đâu?

gh actions-lock --verify-local không dùng mạng, chỉ kiểm tra coverage: tham chiếu uses đã có mục hay chưa. Phù hợp trước commit nhưng không xác minh nguồn gốc. gh actions-lock --verify thực hiện xác minh trực tuyến; runner kiểm tra lại khi job bắt đầu. Hai kết quả xanh mang ý nghĩa khác nhau.

Nếu PR song song thêm action mà quên cập nhật lockfile, kiểm tra cục bộ có thể tìm ra mục thiếu. Đủ mục không chứng minh nguồn gốc hay độ an toàn của mã. Hình thứ hai tóm tắt tài liệu; bài này không cài hoặc chạy CLI để tạo kết quả.

So sánh tự dựng theo tài liệu CLI chính thức: coverage ngoại tuyến bằng --verify-local và nguồn gốc trực tuyến bằng --verify. Không phải kết quả thực thi.
So sánh tự dựng theo tài liệu CLI chính thức: coverage ngoại tuyến bằng --verify-local và nguồn gốc trực tuyến bằng --verify. Không phải kết quả thực thi.

Workflow tái sử dụng có ranh giới kho riêng

Các phụ thuộc action bắc cầu được bao phủ, nhưng lời gọi qua jobs.<job_id>.uses không được lockfile ghim. Cần dùng SHA commit đầy đủ cho lời gọi đó. Action bên trong theo lockfile của kho định nghĩa workflow, không phải kho gọi.

Giả sử kho ứng dụng gọi workflow triển khai từ kho nền tảng. Chỉ đọc actions.lock của ứng dụng không cho biết action phía nền tảng được ghim ra sao. Phải đọc SHA lời gọi cùng thay đổi phụ thuộc của nền tảng. Ảnh runner, đầu vào và secret vẫn riêng biệt: ghim action không đóng băng cả môi trường.

Đọc hai tệp cùng nhau trong PR cập nhật

Khi Dependabot cập nhật phiên bản action của workflow đã áp dụng, nó tạo lại mục lockfile tương ứng trong cùng PR. Có thể so sánh phiên bản dễ đọc và commit thực. --relock đẩy tham chiếu đã dịch chuyển đến commit mới và ghi tệp; khác với kiểm tra chỉ đọc. Việc xem xét mã vẫn cần thiết.

Require lockfile có thể bắt buộc áp dụng nhưng không xóa ranh giới kho. Bắt đầu từ một workflow giúp hiểu khâu tạo, xem xét và xác minh trực tuyến. Ở dấu xanh tiếp theo, hãy đọc đúng bằng chứng: đủ mục, đúng nguồn gốc hay mã đã được xem xét.

Nguồn và đọc thêm

GitHub Changelog · 2026-10-28

GitHub Docs · Workflow dependency lockfiles

GitHub · gh-actions-lock