Shards and JUnit

A suite that takes too long on one machine can run across several. Each machine runs a share of the test files, and one job joins the results.

Split the suiteCopy Anchor Link

--shard 2/4 runs the second of four shares. Each share is every fourth test file, so the four machines together run them all.

strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: npx @danwo/cli test --shard ${{ matrix.shard }}/4
  - uses: actions/upload-artifact@v4
    with: { name: "results-${{ matrix.shard }}", path: .danwo/results }

Each shard keeps its results in .danwo/results/. A shard posts no pull request comment.

Join the resultsCopy Anchor Link

In a later job, download every results-* artifact into .danwo/results, then merge:

- uses: actions/download-artifact@v4
  with: { pattern: "results-*", path: .danwo/results, merge-multiple: true }
- run: npx @danwo/cli merge-reports --reporter github
  env:
    GITHUB_TOKEN: ${{ github.token }}

merge-reports posts one check and one comment for the whole run.

Rerun what failedCopy Anchor Link

--last-failed runs only what failed in the latest run, and merges into it:

npx @danwo/cli test --last-failed

A test that failed before and passes now is reported once, as flaky. A test that fails and then passes on a retry in the same run is flaky too: it passes the run, and the summary and the check say so.

JUnit for other CIsCopy Anchor Link

npx @danwo/cli test --reporter junit

That writes .danwo/junit.xml, which GitLab, Jenkins, CircleCI and Buildkite read.

Stop earlyCopy Anchor Link

--max-failures 5 starts no new test file once five tests have failed.

NextCopy Anchor Link