Ngày 18/9/2026, GitHub thông báo bạn có thể quản lý luật độ phủ mã (code coverage ruleset) bằng REST API, thay vì chỉ thao tác qua giao diện web như trước. Theo trang changelog chính thức của GitHub, tùy chọn Restrict code coverage nay đã sẵn sàng để tạo, cập nhật và đọc bằng lập trình.
Với các đội phát triển ở Việt Nam đang siết chất lượng mã, đây là thay đổi nhỏ nhưng đúng chỗ. Trước đây, muốn áp một ngưỡng độ phủ cho từng kho mã, bạn phải bấm tay trong giao diện. Nay việc đó có thể đưa vào script và tự động hóa cho hàng chục kho cùng lúc, đúng tinh thần cấu hình như mã nguồn.
Có gì mới
Điểm cốt lõi: luật độ phủ mã, vốn chỉ chỉnh được trong giao diện web, nay có thêm đường quản lý qua REST API. Theo GitHub, luật này cho phép hai kiểu ràng buộc chính:
- Bắt buộc một mức phần trăm độ phủ tối thiểu, tính theo độ phủ dòng (line coverage).
- Đặt mức giảm độ phủ tối đa có thể chấp nhận cho một pull request, để một thay đổi không kéo tụt chất lượng kiểm thử của cả dự án.
Nhờ REST API, bạn có thể tạo mới, cập nhật và đọc lại luật này bằng các lệnh gọi API, thay vì phải vào từng kho bấm chỉnh thủ công.
Ai được lợi, ai không
Người hưởng lợi rõ nhất là đội có nhiều kho mã và muốn áp cùng một chuẩn chất lượng cho tất cả. Thay vì chỉnh tay từng nơi, họ viết một lần rồi chạy cho cả tổ chức, giảm sai lệch giữa các dự án và dễ soát lại khi cần.
Có hai giới hạn cần biết. Theo GitHub, tính năng có trên GitHub Enterprise Cloud và GitHub Team, nhưng chưa có trên GitHub Enterprise Server. Ngoài ra, kho mã phải bật GitHub Code Quality và đã cấu hình tải dữ liệu độ phủ (coverage uploads) thì luật này mới có tác dụng. Đội nhỏ dùng gói cá nhân, hoặc chưa dựng bước đo độ phủ trong quy trình tích hợp liên tục, sẽ chưa dùng được ngay.
Hai kiểu ràng buộc mà luật hỗ trợ nhắm vào hai nỗi lo khác nhau. Ngưỡng phần trăm tối thiểu tính theo độ phủ dòng đặt ra một sàn chung, để không ai gộp mã gần như không có kiểm thử. Mức giảm tối đa cho mỗi pull request lại canh chiều hướng: một dự án đang có độ phủ cao vẫn có thể bị bào mòn dần qua từng thay đổi nhỏ, và ràng buộc này chặn đúng kiểu tụt dốc âm thầm đó. Tùy đội đang ở giai đoạn nào, bạn có thể chọn một trong hai hoặc dùng cả hai.
Cách dùng
1. Chuẩn bị điều kiện
Bật GitHub Code Quality cho kho mã và cấu hình để pipeline của bạn tải kết quả độ phủ lên GitHub sau mỗi lần chạy kiểm thử. Không có dữ liệu độ phủ thì luật không có gì để so.
2. Định nghĩa luật bằng API
Dùng REST API để tạo hoặc cập nhật ruleset với điều kiện code coverage, ví dụ đặt ngưỡng phần trăm tối thiểu hoặc mức giảm tối đa cho mỗi pull request. Vì là API, bạn có thể lưu cấu hình này trong kho hạ tầng và áp cho nhiều repo cùng lúc.
3. Đưa vào quy trình duyệt PR
Khi luật đã bật, các pull request không đạt ngưỡng độ phủ sẽ bị chặn theo đúng ràng buộc bạn đặt, giúp việc gác cổng chất lượng diễn ra tự động thay vì phụ thuộc người nhắc.
So với lựa chọn khác trên site
Việc gác cổng độ phủ mã không mới với người dùng GitHub, nhưng đưa được nó vào API là bước tiến cho các đội thích tự động hóa. Trên GitLab, việc đặt ngưỡng độ phủ và chặn merge theo chất lượng cũng là thực hành quen thuộc trong pipeline, nên nếu bạn đang cân nhắc giữa hai nền tảng, khả năng cấu hình luật bằng mã là một tiêu chí đáng so. Với đội đã quen viết cấu hình như mã, việc quản lý ruleset bằng REST API giúp đồng bộ chuẩn chất lượng cho toàn bộ dự án dễ hơn nhiều so với bấm tay.
Nên làm gì bây giờ
Nếu đội bạn dùng GitHub Team hoặc Enterprise Cloud và đang muốn siết độ phủ mã, hãy kiểm tra xem kho đã bật GitHub Code Quality và tải dữ liệu độ phủ chưa, rồi thử định nghĩa một ruleset qua REST API cho một kho mẫu trước khi nhân rộng. Vì phạm vi khả dụng và cách gọi API có thể thay đổi, bạn nên đọc lại tài liệu tại trang chính thức của GitHub trước khi triển khai rộng. Nguồn: GitHub Changelog.
