Bạn tách kiểm tra và báo cáo thành hai job, nối chúng bằng needs. Khi kiểm tra thất bại, job báo cáo lại bị skip đúng lúc bạn cần thông tin nhất. needs mặc định yêu cầu các job phụ thuộc hoàn tất thành công; thứ tự khai báo job không thay đổi điều kiện này.
Bài đọc tài liệu GitHub Actions ngày 07/11/2026. Workflow được parse YAML, script được kiểm cú pháp và chạy cục bộ với biến kết quả giả lập. Chưa upload workflow hay chạy hosted runner. Các trạng thái trên GitHub bên dưới là tiêu chí bạn cần đối chiếu khi chạy thử, không phải log của một lượt CI đã triển khai.
Phân biệt chờ hoàn tất với yêu cầu thành công
Nếu một job lỗi hoặc bị skip, job cần nó cũng có thể bị skip theo chuỗi phụ thuộc, trừ khi có điều kiện phù hợp để tiếp tục. Với báo cáo chỉ đọc kết quả, có thể đặt điều kiện trạng thái ở cấp job để cho phép chạy sau lỗi.
Mẫu dùng !cancelled() theo hướng dẫn biểu thức GitHub: báo cáo được phép chạy khi workflow chưa bị hủy. Đây không phải điều kiện dành cho một job deploy. Luồng triển khai vẫn cần cổng kiểm tra thành công theo yêu cầu của dự án.
1. Workflow chỉ in kết quả job trước
Lưu file .github/workflows/needs-report-demo.yml trong repository thử nghiệm. File cần có trên nhánh mặc định để được nhận diện cho thao tác chạy thủ công:
name: Needs report demo
'on':
workflow_dispatch:
permissions: {}
jobs:
probe:
runs-on: ubuntu-latest
timeout-minutes: 2
steps:
- name: Deliberately fail
shell: bash
run: |
printf '%s\n' 'Probe fails intentionally'
exit 7
report:
needs: probe
if: ${{ !cancelled() }}
runs-on: ubuntu-latest
timeout-minutes: 2
steps:
- name: Print upstream job result
env:
PROBE_RESULT: ${{ needs.probe.result }}
shell: bash
run: |
printf 'probe result=%s\n' "$PROBE_RESULT"Không có checkout, deploy, secret hoặc action bên ngoài trong demo. ubuntu-latest là nhãn image có thể thay đổi; các script chỉ dùng lệnh shell đơn giản, không phụ thuộc package phiên bản cụ thể của image.
Khi tự chạy, job probe phải thất bại do exit 7. Nếu workflow không bị hủy, report cần chạy và in kết quả failure. Việc report thành công không xóa thất bại của probe; workflow thử vẫn phải thể hiện lỗi gốc.
2. Làm ca đối chứng với điều kiện mặc định
Trong bản workflow thử thứ hai, bỏ dòng if của job report rồi chạy lại với probe vẫn lỗi. Đối chiếu report bị skip với bản có điều kiện trạng thái. Thử thêm probe exit 0 để xác nhận report đọc success ở đường chạy thành công.
Không thêm continue-on-error cho probe chỉ để khiến report chạy. Cách đó đổi chính sách chấp nhận lỗi của bước hoặc job. Ở bài này, yêu cầu là giữ lỗi nhưng vẫn đọc được kết quả trong một job báo cáo riêng.
Đọc đúng context và phạm vi phụ thuộc
needs.probe.result là kết quả của job phụ thuộc trực tiếp. Nó có thể là success, failure, cancelled hoặc skipped. Đừng lấy steps.probe.outcome để thay thế: steps là context của các step trong cùng một job, không phải danh sách mọi job của workflow.
Context needs cũng không tự chứa mọi tổ tiên gián tiếp. Nếu cấu trúc là build rồi test rồi report, xác định rõ report trực tiếp cần job nào và đọc đúng các kết quả tương ứng. Không thêm nhiều dependency chỉ vì tên job ấy có tồn tại trong YAML.
Kiểm tra các đường chạy còn lại
Thử thành công, lỗi và hủy thủ công trong repository demo trước khi áp dụng vào CI chính. !cancelled() có ý nghĩa khác always(), nhất là lúc người dùng đã yêu cầu dừng. Tránh hứa job báo cáo chắc chắn chạy trong mọi sự cố runner, quota hoặc hạ tầng chỉ từ một điều kiện YAML.
Nếu job phải tải artifact của job lỗi, kiểm tra artifact có thật sự được tạo ra trước khi bước lỗi xảy ra hay không. Workflow mẫu chưa upload hoặc download artifact, nên nó chỉ chứng minh cấu trúc cần thử cho việc đọc result.
Giữ job báo cáo nhỏ, chỉ nhận quyền cần thiết và giới hạn thời gian. Khi đưa vào dự án, đọc đồ thị phụ thuộc cùng trạng thái của từng job; một job báo cáo xanh không đồng nghĩa toàn bộ kiểm tra trước đó đã qua.
