CI/CD for QA — GitHub Actions Pipeline Guide (2026)
The complete GitHub Actions setup for QA teams: matrix browsers, parallel sharding, flaky-test retries, PR comments, sub-10-minute pipelines, and cost-aware caching.
Last updated 2026-07-20 · 12 min read · By Avinash K
A slow CI pipeline is a silent tax on your team. This guide gets you from a 40-minute serial run to a sub-10-minute sharded pipeline on GitHub Actions — the exact setup we ship on client projects, including cache tuning, retry rules, and the PR comment step that makes results visible.
Key takeaways
- Matrix browsers + shard fanout.
- Cache strategy that actually hits.
- Flaky-test retry rules (2 max, quarantine after 3).
- PR comment with pass/fail summary.
1. Matrix + sharding
strategy:
fail-fast: false
matrix:
project: [chromium, firefox, webkit]
shard: [1/4, 2/4, 3/4, 4/4]
steps:
- run: npx playwright test --project=${{ matrix.project }} --shard=${{ matrix.shard }}3 browsers × 4 shards = 12 parallel jobs. A 40-min suite drops to ~10.
2. Cache that hits
- uses: actions/cache@v4
with:
path: |
~/.cache/ms-playwright
node_modules
key: pw-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
- run: npm ci
- run: npx playwright install --with-depsKey on the lockfile hash. The --with-deps flag re-downloads only when the cache misses.
3. Retry + quarantine rules
In playwright.config.ts set retries: process.env.CI ? 2 : 0. When a test needs a 2nd retry >3 runs in a row, tag it @flaky and exclude from PR gate — quarantine, don't ignore. Root-cause weekly. See our flaky tests guide.
4. PR summary comment
Use playwright-report-summary to post a pass/fail table as a PR comment. Combine with actions/upload-artifact for the HTML report and GitHub Pages for a permalink. Cost: ~$0.008/min on Linux runners at scale — track it, our matrix above adds up fast. Related: Playwright fixtures, POM guide, and Newman in CI.
Once the workflow runs green, the next win is ordering: cheap checks first, browsers last. Our guide to shift-left testing in DevOps covers that sequencing, and the test-driven development (TDD) guide for QA engineers explains how to get a fast, meaningful unit layer to put first.