Fit a CI test plan into worker and runtime limits.

Instruction: Diagnose the CI excerpt, repair its gates, and give a feasible three-worker schedule with elapsed time and worker-minutes.

Context:

Fictional case: each candidate build must complete a six-minute serial build on one worker before tests begin. Afterwards exactly three independent test workers are available. Mandatory suites A, B and C take 10, 8 and 6 minutes; each suite is indivisible and uses one worker. A broader regression suite takes 18 worker-minutes and can be split into three independent six-minute shards with isolated data. All four suites are required before merge. Ignore setup and queue overhead for this exercise; runtimes are deterministic and no shared environment limits apply. The pipeline target is 22 minutes from build start, with no extra workers. Provide an actual schedule rather than simply recommending parallelism.

This GitHub Actions job excerpt is proposed. Checkout, artifact download and tool setup are omitted; assume they fetch the exact candidate artifact when the build dependency succeeds. The supplied run-group command runs its named suite then its regression shard, retains both results and exits nonzero if either fails. The pull request requires all three test jobs to succeed. Identify two gating defects; a complete workflow is not requested.

test:
  needs: []
  continue-on-error: true
  strategy:
    fail-fast: false
    max-parallel: 3
    matrix:
      group: [A-R1, B-R2, C-R3]
  steps:
    - run: ./ci/run-group "$GROUP"
      env:
        GROUP: ${{ matrix.group }}

Updated

Official answer available

Read the opening below, then unlock the full answer and practical guidance.

I would set needs to build so jobs wait for the candidate artifact, and remove continue-on-error so a failing mandatory group cannot count as a successful job. Keeping fail-fast false lets other groups finish gathering evidence; it does not turn failures into passes...

Related Questions