Skip to content
🎉 Launch sale:50% off everything over $22 — automatically applied at checkout· ends Aug 2Shop the sale →
DevOps AI ToolKit
Newsletter
All prompts
AI for GitLab CI/CD Difficulty: Intermediate ClaudeChatGPT

GitLab CI/CD Flaky Test Retry & Job Resilience Prompt

Tame flaky pipelines with targeted retry: rules, timeouts, allow_failure exit codes, and a quarantine workflow — without masking real failures or burning compute on doomed jobs.

Target user
Engineers fighting intermittent red pipelines
Difficulty
Intermediate
Tools
Claude, ChatGPT

The prompt

You are a CI reliability engineer who distinguishes "flaky infrastructure" from "flaky tests" from "real bugs" and treats each differently.

I will provide:
- Jobs that fail intermittently and their typical error output
- Whether failures cluster (runner/network) or are test-specific
- Current `retry`, `timeout`, and `allow_failure` settings

Your job:

1. **Classify the flakiness** — infrastructure (runner_system_failure, dns, registry pull), resource (OOM, timeout), or genuine test nondeterminism — because the fix differs for each.

2. **Scope `retry` precisely** — use the object form `retry: { max: 2, when: [runner_system_failure, stuck_or_timeout_failure, api_failure] }` so only infra classes retry, NOT `script_failure` (which would mask real bugs). List every valid `when:` value and what it means.

3. **Set sane `timeout`** per job and explain its interaction with the project/runner timeout (the smaller wins), plus how a too-generous timeout hides a hang.

4. **`allow_failure` with `exit_codes`** — let a job soft-fail only on specific exit codes (e.g. a known-flaky integration suite returning 75) while still failing on real errors.

5. **Quarantine workflow** — a separate manual or scheduled `flaky-tests` job that runs known-quarantined tests `allow_failure: true`, tracked in an issue, so the main pipeline stays green-meaningful.

6. **Test-runner-level retries** — when to push retries down into the framework (jest `--retries`, pytest-rerunfailures) vs the GitLab job level, and why job-level retry re-runs the WHOLE job (expensive).

7. **Measure** — propose tracking flaky rate per job (failures that pass on retry) so flakiness is visible and trends down, not normalized.

Output: (a) corrected `retry`/`timeout`/`allow_failure` per job, (b) a quarantine job template + issue-tracking convention, (c) a decision table: symptom → retry vs quarantine vs fix-the-test, (d) a flaky-rate metric definition.

Bias toward: retrying only infra classes, never `script_failure`; making flakiness visible rather than silently retried away.

Run this prompt with AI

Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.

Related prompts

More GitLab CI/CD prompts & error guides

Browse every GitLab CI/CD prompt and troubleshooting guide in one place.

Free download · 368-page PDF

Reading prompts? Get all 500 in one free PDF

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.