Bạn chạy test qua nhiều shard hoặc nhiều cấu hình, nhưng chỉ thấy log của cấu hình lỗi đầu tiên; các job khác bị hủy khi chưa hoàn tất. Khi cần thu đủ kết quả để chẩn đoán, hãy xem strategy.fail-fast. Đặt false giúp các lượt còn lại trong matrix tiếp tục theo chính sách đó, không biến lỗi thành một kết quả thành công.
Bài đối chiếu GitHub Docs ngày 10/11/2026. YAML được phân tích tại máy; script Bash được kiểm tra cú pháp và chạy riêng với các giá trị shard giả lập. Chưa gửi workflow lên GitHub, quan sát scheduler, hủy job hoặc đo chi phí hosted runner. Ví dụ không dùng action bên ngoài hay thao tác repository.
Hai câu hỏi cần tách riêng
Workflow syntax mô tả fail-fast áp dụng cho matrix, với mặc định true. Khi một job liên quan thất bại theo chính sách, các job matrix còn đang chạy hoặc chờ có thể bị hủy. Đặt false thay đổi quy tắc hủy này.
continue-on-error là lựa chọn khác, liên quan đến cách chấp nhận lỗi của job hoặc step ở phạm vi tương ứng. Đừng thêm nó chỉ vì mục đích là nhìn đủ log. Trong ví dụ bên dưới, không cấu hình continue-on-error, nên shard lỗi vẫn cần được xem là lỗi của kiểm tra.
Workflow ba shard có một lỗi cố ý
Lưu vào .github/workflows/matrix-demo.yml của repository thử nghiệm nếu bạn muốn kiểm tra trên GitHub:
name: Matrix failure demo
"on": workflow_dispatch
permissions: {}
jobs:
probe:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shard: [alpha, beta, gamma]
steps:
- name: Probe one shard
env:
SHARD: ${{ matrix.shard }}
shell: bash
run: |
set -euo pipefail
case "$SHARD" in
alpha|gamma)
printf 'PASS %s\n' "$SHARD"
;;
beta)
printf 'Intentional failure: %s\n' "$SHARD" >&2
exit 7
;;
*)
printf 'Unknown shard\n' >&2
exit 2
;;
esacMatrix khai báo ba giá trị shard nên tạo ba biến thể job. Beta cố tình trả exit code 7; alpha và gamma in thông báo rồi thành công. Expression đi qua env và script đọc biến được quote, giúp dữ liệu shard không bị ghép trực tiếp thành mã shell.
Chạy Bash local với từng giá trị xác nhận được đúng các nhánh 0, 7 và 0; thêm giá trị không biết trả 2. Nó không chứng minh GitHub sẽ xếp các job vào thời điểm nào. Phần hành vi của matrix cần được kiểm tra bằng lần chạy workflow thật nếu bạn áp dụng ví dụ.
Quan sát điều gì trên GitHub?
Với fail-fast false, kế hoạch kiểm tra là xem cả ba biến thể có cơ hội hoàn tất mà không bị quy tắc fail-fast hủy vì beta lỗi. Beta vẫn cần hiển thị thất bại. Nếu lượt chạy bị hủy thủ công, timeout hoặc chịu một cơ chế hủy khác, false không phải lời bảo đảm rằng mọi job luôn hoàn tất.
Để so sánh, tạo một lượt thử riêng chỉ đổi fail-fast thành true. Các job đã xong trước khi phát hiện lỗi vẫn có thể đã có kết quả; không suy từ một lần chạy rằng shard nào luôn chạy trước hoặc luôn bị hủy. Tài liệu Running variations of jobs trình bày chính sách xử lý lỗi và matrix.
Chọn theo mục đích của lượt kiểm tra
Nếu đang điều tra lỗi trên nhiều cấu hình độc lập, thu đủ kết quả có thể hữu ích. Nếu một thất bại đã đủ để dừng một lượt không cần tiếp tục tiêu tốn tài nguyên, mặc định fail-fast có vai trò riêng. Quyết định này cần tính đến thời gian chạy và nhu cầu chẩn đoán, không chỉ mong workflow hiển thị nhiều ô xanh.
Không suy rằng fail-fast false đồng nghĩa vô hạn tài nguyên hoặc mọi job chạy song song ngay. Runner có thể chưa sẵn sàng; giới hạn song song và timeout là các cấu hình khác. Ví dụ không thay chúng và không có số đo chi phí để kết luận phương án nào rẻ hơn.
Lỗi thường gặp khi review
- Đặt fail-fast ở một step: kiểm tra lại vị trí dưới strategy của job matrix.
- Thêm continue-on-error để giữ log: xác nhận bạn có thật sự muốn chấp nhận lỗi hay chỉ muốn các job khác tiếp tục.
- Cho rằng false vô hiệu hóa mọi loại cancellation: rà cả thao tác hủy và các chính sách workflow khác.
- Chỉ thử shard thành công: giữ một ca lỗi có mã trả về biết trước để quan sát chính sách.
Hãy bắt đầu bằng một matrix nhỏ như fixture này. Khi bạn phân biệt được “tiếp tục thu kết quả” với “cho phép thất bại”, cấu hình pipeline sẽ thể hiện đúng điều nhóm cần.
