Chuyển đổi sang Ubuntu 26.04 trên GitHub Actions: Kiểm tra sự khác biệt của runner từ cùng một commit
Kết quả CI có thể thay đổi ngay cả khi mã nguồn không hề thay đổi. Nếu quy trình làm việc (workflow) phụ thuộc vào ubuntu-latest cho môi trường thực thi, việc chuyển đổi image hệ điều hành cũng phải được tính vào các thay đổi mà đội ngũ cần quản lý.
GitHub đã công bố hỗ trợ chính thức cho runner Ubuntu 26.04 và kế hoạch chuyển đổi ubuntu-latest vào ngày 17 tháng 9 năm 2026. Bài viết này không nhằm giới thiệu rằng image mới nhất thiết phải nhanh hơn, mà là một đề xuất thực tế để cô lập và kiểm tra sự khác biệt về môi trường bằng cách sử dụng cùng một commit.
Phạm vi được xác nhận trong thông báo chính thức
Theo thông báo, image Ubuntu 26.04 được hỗ trợ chính thức trên x64 và arm64 với các nhãn tường minh là ubuntu-26.04 và ubuntu-26.04-arm. ubuntu-latest dự kiến sẽ dần chuyển đổi từ Ubuntu 24.04 sang 26.04 từ ngày 19 tháng 10 đến ngày 19 tháng 11 năm 2026.
Image mới có các công cụ được cập nhật hoặc loại bỏ, do đó các bản build phụ thuộc vào các gói cài sẵn có thể bị ảnh hưởng. Nếu việc chuẩn bị chưa hoàn tất, GitHub hướng dẫn cách chỉ định rõ ubuntu-24.04. Lịch trình này không nhất thiết đại diện cho ngày chuyển đổi thực tế của tất cả các kho lưu trữ.
Ghi lại môi trường mà kho lưu trữ của bạn kỳ vọng
Trước tiên, hãy kiểm tra runs-on trong các workflow và workflow tái sử dụng (reusable workflows). Đừng vội cho rằng ảnh hưởng từ máy chủ host sẽ biến mất chỉ vì bạn đang dùng container; bạn cũng nên xem xét các bước cài đặt, nén và tải lên (upload) được thực thi bên ngoài container.
Hãy thử chia checklist thành trình biên dịch, runtime, trình quản lý gói và thư viện hệ thống. Thay vì chỉ ghi tên công cụ, việc liên kết nơi cài đặt và bước nào gọi công cụ đó sẽ giúp bạn dễ dàng thu hẹp nguyên nhân trong nhật ký (log) lỗi.
Cùng một commit, hai môi trường, các artifact độc lập
Việc diễn tập chuyển đổi sẽ rõ ràng hơn nếu bắt đầu từ một luồng kiểm thử không có quyền triển khai (deploy). Hãy chạy cùng một commit và lockfile trên cả image cũ lẫn image mới, đồng thời lưu riêng log, kết quả kiểm thử và tên artifact. Đây là phương pháp xác thực được đề xuất trong bài viết này.
Trong lần so sánh ban đầu, hãy ghi lại các điều kiện cache để có thể phân biệt tác động của cache cũ. Ngoài trạng thái build thành công hay thất bại, bạn cần lưu lại phiên bản công cụ đã cài đặt, bước bị lỗi và kết quả thực thi artifact để phân biệt các kết quả vượt qua chỉ vì ăn may nhờ cache hit.
Xác thực sau dấu tích xanh
Nếu là dự án web, bạn có thể kiểm tra xem các tệp đã tạo có thực sự phục vụ (serve) được không; nếu có các dependency native, hãy kiểm tra xem chúng có tải được trong môi trường mục tiêu hay không. Thay vì áp dụng quy tắc mọi byte của artifact phải giống hệt nhau, hãy phân biệt giữa các khác biệt phi tất định (non-deterministic) như dấu thời gian (timestamp) với các khác biệt về mặt chức năng để đánh giá.
Người đánh giá (reviewer) cần có thể xem liên kết chạy image mới, sự khác biệt về phiên bản công cụ, kết quả kiểm tra chức năng tiêu biểu và các thay đổi cần hoàn tác ở cùng một nơi. Nếu kết hợp việc chuyển đổi runner với refactor ứng dụng, nguyên nhân lỗi và phạm vi rollback sẽ bị mở rộng không cần thiết.
Lợi ích và giới hạn còn lại của việc cố định image
Việc sử dụng nhãn hệ điều hành tường minh giúp kiểm soát các đợt chuyển đổi lớn, nhưng không đồng nghĩa với một môi trường build hoàn toàn bất biến. Hãy duy trì thói quen cài đặt tường minh các công cụ cần thiết cho việc thực thi và ghi lại phiên bản thực tế vào log.
Đối với các kho lưu trữ nhỏ, không cần thiết phải xây dựng một hệ thống xác thực đồ sộ mới. Bạn có thể bắt đầu bằng cách so sánh một bản build tiêu biểu cùng với các dependency nhạy cảm nhất, và nếu áp dụng việc ghim tạm thời, hãy ghi lại người phụ trách gỡ bỏ cùng ngày sẽ xem xét lại.
Tách biệt thảo luận công khai với quyết định của đội ngũ
Các issue công khai trên runner-images là kênh để kiểm tra các thay đổi của image và báo cáo sự cố. Một bình luận cụ thể hay thất bại của dự án khác không đồng nghĩa với việc sự cố đó sẽ tái diễn trong kho lưu trữ của bạn, và bài viết này không đưa ra khẳng định về sự đồng thuận của cộng đồng hay tần suất sự cố bằng các con số.
Việc cần làm hôm nay là tìm kiếm những nơi đang sử dụng nhãn latest và thử nghiệm cùng một commit trên image mới. Nếu bạn ghi sẵn các điều kiện pass và điều kiện tạm hoãn từ trước, ngay cả khi bản build thay đổi trong giai đoạn chuyển đổi thực tế, người phụ trách vẫn có thể đưa ra đánh giá dựa trên cùng một bằng chứng rõ ràng.