GitHub Actions cache-mode: Kiểm tra quyền cache ẩn sau màu xanh CI
Nếu CI kết thúc với màu xanh nhưng lần chạy tiếp theo lại tải lại các dependency, bạn rất dễ có xu hướng sửa cache key trước tiên. Giờ đây, bạn cũng cần kiểm tra xem liệu việc lưu trữ có bị bỏ qua do quyền hạn hay không. Bởi vì một workflow thành công không đồng nghĩa với việc cache đã được tạo.
GitHub đã công bố tính năng General Availability (GA) cho cache-mode vào ngày 10 tháng 9 năm 2026. Bạn có thể thiết lập quyền truy cập cache ở cấp độ workflow hoặc job trên tất cả các gói của github.com. Đi xa hơn một bước so với bài viết trước về giá trị mặc định chỉ đọc (read-only), lần này chúng ta sẽ tập trung vào cấu hình tường minh và phương pháp xác thực.
Tính năng đã xác nhận: Bốn tổ hợp khôi phục và lưu trữ
read chỉ cho phép khôi phục (restore), write cho phép cả khôi phục lẫn lưu trữ (save). write-only chỉ cho phép lưu trữ và none chặn cả hai. Điểm kiểm tra đầu tiên là đừng hiểu nhầm tên gọi write là chỉ dùng để lưu trữ.
Giá trị được khai báo trong job sẽ được ưu tiên hơn cấu hình toàn workflow. Ngược lại, trong lệnh gọi reusable workflow, nó không thể nhận quyền truy cập lớn hơn mức mà caller cho phép. Đừng chỉ đọc khai báo trong một tệp duy nhất rồi đưa ra phán đoán về quyền thực tế của toàn bộ lần chạy.
Lần chạy xanh cũng không phải là bằng chứng của việc lưu trữ
Tài liệu chính thức giải thích rằng các thao tác cache không được phép sẽ để lại log thông báo và tiếp tục thực thi. Việc khôi phục bị chặn sẽ được xử lý như một cache miss, và việc lưu trữ bị chặn sẽ không được thực hiện. Điểm cốt lõi trong việc quan sát là bản thân workflow sẽ không bị thất bại.
Vì vậy, việc chia nhật ký vận hành thành trạng thái thành công của lần chạy và kết quả cache sẽ hữu ích hơn. Hãy kiểm tra trong cùng một lần chạy xem event nào đã kích hoạt, mode nào đã được áp dụng, liệu việc khôi phục đã diễn ra hay việc lưu trữ đã bị bỏ qua. Đây là phương thức vận hành được đề xuất dựa trên mô tả tính năng chính thức, chứ không phải là tính năng dashboard mới được cung cấp tự động.
Lập bảng quyền hạn nhỏ trước khi áp dụng
Hãy mở các workflow thực tế của kho lưu trữ để tìm ra job nào tạo cache và job nào sử dụng cache. Bạn không cần phải gộp job chuẩn bị dependency trên branch đáng tin cậy, job thử nghiệm thay đổi bên ngoài và job xác thực artifact triển khai vào cùng một mức quyền hạn.
Hãy viết ra hai câu hỏi cho mỗi job: Job này có cần đọc cache hiện có không? Kết quả của job này có được phép để lại cho lần chạy tiếp theo đọc không? Nếu cả hai đều không cần thiết, bạn có thể xem xét lại thói quen gắn cache theo quán tính. Tuy nhiên, cấu hình thực tế phải được quyết định dựa trên ranh giới tin cậy (trust boundary) và cấu trúc bản dựng của kho lưu trữ.
Thử nghiệm tối thiểu: Job tiêu thụ chỉ đọc (read-only)
Ví dụ, trong workflow dành cho kiểm thử, hãy chỉ định cache-mode: read ở cấp cao nhất và đảm bảo không có ghi đè theo từng job. Hãy so sánh xem kết quả kiểm thử khi dùng cache và khi không có cache có giống nhau không. Cache nên là một phương tiện phụ trợ để giảm thời gian thực thi; nếu tính chính xác thay đổi khi không có cache, bạn cần kiểm tra lại các giả định về bản dựng trước.
Tiêu chuẩn vượt qua thử nghiệm này không phải là một dòng CI thành công. Bạn phải giải thích được nỗ lực khôi phục và việc bỏ qua lưu trữ, đồng thời có thể xác thực lại với cùng đầu vào trong lần chạy tiếp theo. Việc ghi lại commit trước và sau thử nghiệm, trigger, cấu hình có hiệu lực và vị trí log sẽ giúp các đồng nghiệp khác dễ dàng tái hiện đánh giá.
Đọc đường dẫn gọi đối với reusable workflow
Ngay cả khi bạn đã đặt các giá trị mặc định an toàn trong workflow dùng chung, bạn vẫn phải xem xét cả bên gọi lẫn cấu hình của từng job riêng lẻ. Việc các kho lưu trữ gọi cùng một tệp không đồng nghĩa với việc chúng được thực thi với cùng một mức quyền hạn.
Khi đánh giá, hãy lần theo thứ tự bắt đầu từ caller, đến khai báo cache của job, rồi đến workflow được gọi. Nếu quyền hạn dự kiến khác với log thực tế, hãy tìm nguồn gốc của cấu hình trước khi làm phức tạp thêm key. Đây là gợi ý nhằm giảm thời gian chẩn đoán trong các tổ chức có nhiều workflow tái sử dụng, chứ không đại diện cho chỉ số cải thiện hiệu năng đã được đo lường.
Các ngoại lệ cần lưu ý và thứ tự áp dụng
Nếu bạn chỉ định write hoặc write-only cho các event có mức độ tin cậy thấp như pull_request_target, bạn có thể ghi đè các giới hạn chỉ đọc mặc định và làm tăng nguy cơ ô nhiễm cache (cache poisoning). GitHub sẽ thêm cảnh báo (warning annotation) trong trường hợp này. Bạn nên tránh cách xử lý mở rộng quyền ghi chỉ để làm biến mất cảnh báo.
Ngược lại, lựa chọn chặn toàn bộ cache cũng có cái giá của nó. Thời gian tải xuống và bản dựng có thể tăng lên, vì vậy hãy trực tiếp so sánh thời gian thực thi trên một job tiêu biểu trước khi mở rộng phạm vi. Thay vì ước lượng số liệu để hứa hẹn hiệu quả hiệu năng, tốt hơn hết là nhóm nên cùng nhau quyết định các giới hạn cần thiết về mặt bảo mật và độ trễ có thể chấp nhận được.
Những câu hỏi nhóm cần kiểm tra ngay bây giờ
Việc cần làm hôm nay không phải là thêm hàng loạt cấu hình mới vào toàn bộ kho lưu trữ. Đó là tìm ra producer và consumer của cache trong một workflow quan trọng, ghi lại các quyền hạn và xác nhận bằng chứng khôi phục cũng như lưu trữ trong một lần chạy duy nhất. Nếu đó là job triển khai, hãy giữ các thay đổi ở mức nhỏ để người phụ trách có thể đọc log và xem xét liệu nó có khớp với kỳ vọng hay không.
Câu hỏi có thể nảy sinh trong thực tế là: Tại sao bước lưu trữ bị bỏ qua nhưng CI vẫn thành công? Bài viết này giải thích sự nhầm lẫn đó dựa trên hành vi chính thức, không đưa ra khảo sát cộng đồng riêng biệt hay tỷ lệ sự cố phổ quát nào. Khi áp dụng tính năng mới, việc kiểm tra riêng biệt kết quả hiệu năng và kết quả quyền hạn sẽ giúp bạn phân loại chính xác hơn các vấn đề về cache trong tương lai.