Generate a GitHub Actions QA Pipeline with AI
Returns a complete `.github/workflows/qa.yml` with unit → integration → E2E stages, Playwright browser matrix, dependency + browser caching keyed on lockfile, artifact retention with explicit period, and failure notification via webhook / Slack.
When to use it
- Bootstrapping a QA pipeline for a new project.
- Migrating from Jenkins or CircleCI to GitHub Actions.
- Auditing an existing pipeline for missing best practices (cache, artifacts, notifications).
- Standardizing pipelines across multiple repos.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a CI/CD specialist who has shipped QA pipelines for large monorepos. You pin runner versions to lockfile hashes (not 'latest'), externalize secrets via OIDC where possible, and treat test artifacts as evidence — retained for at least 7 days.
</role>
<context>
GitHub Actions best practices for QA pipelines (2026):
- **Cache** keyed on lockfile hash for npm + Playwright browsers
- **Concurrency** group per PR to cancel stale runs
- **Permissions** scoped to least-privilege (no `contents: write` unless needed)
- **OIDC** instead of long-lived secrets where supported
- **Artifacts** for test reports + traces with explicit retention
- **Notifications** on failure to relevant channel (Slack, webhook)
- **Matrix** for cross-browser / cross-OS testing
</context>
<task>
Generate a `.github/workflows/qa.yml` with:
1. Triggers on PR + push to main
2. Concurrency group cancellable per PR
3. Permissions scoped minimally
4. Jobs: install (with cache) → lint → unit → integration → e2e
5. Playwright browser matrix (chromium, firefox, webkit)
6. Cache for npm and Playwright browsers, keyed on package-lock.json
7. Test report + trace artifacts with 7-day retention
8. Failure notification step (Slack incoming webhook or repository_dispatch)
9. Skip e2e on doc-only PRs (paths-ignore)
</task>
<input>
Tech stack: {stack}
Test frameworks: {frameworks}
Notification target (Slack, Teams, custom webhook): {notification}
Special requirements (monorepo, multiple apps, etc.): {special}
</input>
<constraints>
- Pin action versions to commit SHA OR major version (`@v4`), not `@latest`.
- Cache keys MUST include lockfile hash for invalidation.
- Artifacts MUST have explicit retention-days (not default 90).
- Failure notification MUST gate on `if: failure()`.
- Use `fail-fast: false` for E2E matrix so a Firefox failure doesn't kill Chromium run.
- Concurrency group + cancel-in-progress for PR efficiency.
</constraints>
<output_format>
Complete YAML file in a code block. Followed by a "What this gives you" section with bullets on cost, runtime, and what's NOT covered.
</output_format>
Before writing, identify the project's lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml) — caching depends on it.Example
Common pitfalls
- Action versions pinned to '@latest' — breaks reproducibility. Force semver or SHA.
- Artifacts use default 90-day retention — generates noise + cost. Force explicit retention-days.
- fail-fast omitted on E2E matrix — Firefox failure cancels chromium and webkit. Always set fail-fast: false.
- Notification step runs on success too — only fire on failure with `if: failure()`.
Tips
- Use OIDC for cloud deploys (no long-lived AWS access keys). Read GitHub's OIDC docs.
- Use reusable workflows (`uses: ./.github/workflows/reusable.yml`) for multi-repo orgs.
- Add a `merge_group` trigger for merge queues — same workflow runs at queue time.
- Pair with `parallel-test-execution-config` for sharding when E2E suite grows.
FAQ
Cancel stale PR runs via concurrency. Use cache keys aggressively. Run E2E only on PRs touching code (paths-ignore for docs). Consider self-hosted runners for high-volume workflows. Move heavy load tests to a separate weekly schedule.
Related prompts
GitLab CI Test Pipeline Configuration
Returns a `.gitlab-ci.yml` with stages (build, test:unit, test:integration, test:e2e), parallel matrix for E2E browsers, cache keyed on lockfile, rules section for MR vs main differences, and artifact reports with explicit expiration.
Open →Configure Parallel Test Execution
Returns a parallel-execution config tailored to your framework (Playwright or Jest), CI runner count, average test duration, and flakiness rate — including shard count, worker count per shard, test ordering strategy, and a reasoning paragraph.
Open →Test Impact Analysis from Git Diff
Reads a git diff and an import graph and returns the minimal test set to run for that diff — direct hits, transitive impact (1-2 levels), and explicit full-suite triggers (config / migration / lock file changes).
Open →Generate Allure Annotations for Test Files
Reads a test file and annotates each test with Allure metadata (epic, feature, story, severity, link to spec, TMS link) based on file path conventions, commit message JIRA prefixes, and test naming — emits a diff, not a rewrite.
Open →