Bạn bật continue-on-error cho một phép kiểm tra thử nghiệm. Job vẫn xanh dù lệnh kiểm tra trả mã lỗi. Khi step báo cáo đọc conclusion bằng success, cả thông báo của nhóm cũng nói kiểm tra đã qua. Cần phân biệt kết quả gốc của step với kết quả sau khi chính sách cho phép tiếp tục được áp dụng.
Bài đọc tài liệu GitHub Actions ngày 05/11/2026. Workflow mẫu được parse YAML và các script được kiểm cú pháp Bash cục bộ; chưa gửi workflow lên GitHub hoặc chạy hosted runner. Những trạng thái mô tả dưới đây là hợp đồng của tài liệu và tiêu chí kiểm tra khi chạy, không phải log từ một workflow đã triển khai.
Hai trường kết quả của cùng một step
steps.<id>.outcome ghi kết quả trước khi áp dụng continue-on-error. steps.<id>.conclusion ghi kết quả sau khi áp dụng chính sách này. Một step lỗi nhưng được cho tiếp tục có outcome failure và conclusion success.
Hai trường cùng tồn tại để phục vụ hai câu hỏi khác nhau: lệnh đã chạy ra sao, và job nên tiếp tục theo chính sách nào. Đừng dùng conclusion làm bằng chứng duy nhất rằng bộ kiểm tra đã vượt qua tất cả ca kiểm thử.
Context steps chỉ áp dụng cho các step có id đã chạy trong cùng job. Đặt name đẹp để đọc log là chưa đủ: biểu thức dùng id, không dùng nhãn name.
1. Tạo workflow chỉ chạy thủ công
Trong một repository thử nghiệm có quyền dùng Actions, lưu file .github/workflows/outcome-demo.yml. Workflow không checkout code, không deploy và không gọi action bên ngoài:
name: Outcome demo
'on':
workflow_dispatch:
permissions: {}
jobs:
inspect:
runs-on: ubuntu-latest
steps:
- name: Deliberate failed probe
id: probe
continue-on-error: true
shell: bash
run: |
printf '%s\n' 'This probe intentionally fails'
exit 7
- name: Inspect both results
env:
PROBE_OUTCOME: ${{ steps.probe.outcome }}
PROBE_CONCLUSION: ${{ steps.probe.conclusion }}
shell: bash
run: |
printf 'outcome=%s\n' "$PROBE_OUTCOME"
printf 'conclusion=%s\n' "$PROBE_CONCLUSION"Workflow dùng ubuntu-latest nên image runner có thể thay đổi theo thời gian; ví dụ không phụ thuộc một package của image. Sự kiện workflow_dispatch yêu cầu file có trên nhánh mặc định để thao tác chạy thủ công được nhận diện theo quy trình của GitHub.
Khi tự chạy, kiểm tra step đầu có lệnh exit 7, step sau vẫn chạy, và hai dòng báo cáo lần lượt là failure và success. Job mẫu có thể thành công vì lỗi duy nhất được cho phép tiếp tục. Đây là khác biệt có chủ đích của chính sách, không phải việc exit 7 bị biến thành exit 0 trong script.
2. Thu thập chẩn đoán rồi vẫn buộc job thất bại
Nếu phép kiểm tra thực tế là bắt buộc, bỏ continue-on-error là cách trực tiếp. Khi cần chạy bước báo cáo trước rồi mới chặn job, có thể thêm step sau vào cuối danh sách trên:
- name: Enforce required probe
if: ${{ steps.probe.outcome == 'failure' }}
shell: bash
run: |
printf '%s\n' 'Required probe failed'
exit 1Trong demo này, conclusion của probe là success nên các step tiếp theo chưa bị chặn bởi lỗi ấy. Gate đọc outcome để phát hiện lỗi gốc và tự trả mã khác 0. Không đặt continue-on-error cho gate nếu mục tiêu là làm job thất bại.
Nếu job còn nhiều step có thể thất bại hoặc bị hủy, cần thiết kế thêm điều kiện trạng thái và thứ tự thu thập artifact. Mẫu nhỏ không chứng minh mọi đường chạy khi cancel, skip hay nhiều lỗi đồng thời. Đừng sao chép gate rồi mặc định nó chạy trong mọi hoàn cảnh.
Kiểm tra trước khi áp dụng
Thử cả probe exit 0 và exit khác 0. Với exit 0, cả outcome và conclusion phải là success, gate không cần chạy. Với lỗi được cho tiếp tục, báo cáo phải giữ được failure gốc và gate bắt buộc phải làm job thất bại.
Phân biệt cấu hình continue-on-error ở cấp step với cấu hình cùng tên ở cấp job. Bài chỉ dùng cấp step; kết luận về context steps không tự mô tả kết quả của các job phụ thuộc. Khi đổi id của step, tìm lại mọi biểu thức đang tham chiếu id ấy.
Giữ danh sách kiểm tra thử nghiệm được phép lỗi thật nhỏ và nêu rõ mục đích. Một job xanh có thể nghĩa là chính sách đã được tuân thủ; để biết từng phép kiểm tra có qua hay không, báo cáo outcome tương ứng và giữ log đủ để điều tra.
