Generate a 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.
When to use it
- Migrating from Jenkins or GitHub Actions to GitLab CI.
- Standardizing GitLab pipelines across teams or services.
- Adding QA gates to an existing GitLab project.
- Auditing an existing GitLab pipeline for missing best practices.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a GitLab CI specialist. You use stages, rules (not the deprecated 'only/except'), parallel matrix for browser fanout, and `artifacts:reports` for test result integration.
</role>
<context>
GitLab CI structure: stages run sequentially; jobs within a stage run parallel. `rules:` (preferred over deprecated `only/except`) gates jobs by ref / changes / variables. Caching is keyed via cache:key. Artifacts have `expire_in` plus `reports:` for native GitLab integration (Jest, Cobertura, JUnit, etc.).
</context>
<task>
Generate a `.gitlab-ci.yml` with:
1. Stages: build, test:unit, test:integration, test:e2e, notify
2. Cache strategy keyed on lockfile hash
3. Parallel matrix for E2E browsers (chromium, firefox, webkit)
4. Rules: MR vs main pipeline differences (e.g., skip E2E on doc-only changes)
5. Artifacts with `expire_in` and `reports:` for JUnit / coverage
6. Notification job on failure (Slack via webhook or pipeline notification)
7. `needs:` keyword for cross-stage dependencies (faster than purely sequential)
</task>
<input>
Tech stack: {stack}
Test frameworks: {frameworks}
Notification target: {notification}
Special requirements: {special}
</input>
<constraints>
- Use `rules:` not `only/except`.
- Cache key MUST include lockfile hash.
- Artifacts MUST have `expire_in` (not default).
- `reports:` MUST be used for native GitLab test result integration.
- E2E matrix uses `parallel:matrix` keyword (modern syntax).
- Use `needs:` to break strict stage sequencing where beneficial.
</constraints>
<output_format>
Complete YAML in a code block. Followed by "Notes" section: how to wire SSH keys via `CI_JOB_TOKEN`, dynamic environments, and what's NOT covered.
</output_format>
Before writing, decide whether the project benefits from `needs:` (parallel stages) or strict sequential.Example
Common pitfalls
- Model defaults to deprecated `only/except` syntax — force `rules:`.
- Cache key uses static string instead of lockfile-based — cache never invalidates. Use `files:` directive.
- Artifacts get no `expire_in` — accumulates storage cost. Always set.
- JUnit / coverage reports not used — loses native GitLab integration (merge request widgets, test history).
Tips
- Use `needs:` to break strict stage sequencing — significant runtime savings on bigger pipelines.
- Pair with reusable templates via `include:` for org-wide standardization.
- Use protected variables for production secrets (master/protected branches only).
- Pair with `parallel-test-execution-config` for E2E sharding when suite grows.
FAQ
Both cover ~95% of common QA pipeline needs. GitLab leads on built-in container registry, deployments, dependency proxy. GitHub Actions leads on marketplace size and OIDC adoption. Choose based on where your code lives; both can do the job.
Related prompts
GitHub Actions QA Pipeline Generator
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.
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 →