AutoMaxSharding and CI
Split a run across machines, merge reports, and wire AutoMax into GitHub Actions.
How --shard splits a run, how blob reports merge, what the shipped GitHub Actions workflow does,
and how results reach the database and the integrations from CI.
Shard
bun run automax run -p demo-shop -e staging -b chromium --shard 1/3 --run-id gh-123 --reporter blob
bun run automax run -p demo-shop -e staging -b chromium --shard 2/3 --run-id gh-123 --reporter blob
bun run automax run -p demo-shop -e staging -b chromium --shard 3/3 --run-id gh-123 --reporter blob
npx playwright merge-reports --reporter html,junit .automax/runs/gh-123/blob-reportAll shards share the runId, so user-pool leases stay unique (shardOffset + parallelIndex) and ingest merges the NDJSON files of every shard into one run.
The workflow
.github/workflows/ci.yml runs lint, typecheck and unit tests, then the demo project per browser, uploads artifacts, merges reports, ingests when a database or a server token is configured, and calls automax integrations notify with the GitHub token. Pull requests run @smoke; main runs @regression; a nightly job runs the full matrix.
Offline CI
Tag scenarios with @har:<name> and run with --har-replay --strict so the pipeline needs no network access to the application. See Network mocking and HAR.
Ingest from CI
bun run automax report ingest --run-id gh-123 .automax/runs/gh-123/messages*.ndjson # direct DB
bun run automax report ingest --run-id gh-123 --server https://automax.example.com --token $AUTOMAX_TOKEN .automax/runs/gh-123/messages*.ndjsonThe second form uploads through the server with a scoped API token, so CI never holds database credentials.