GitLab CI/CD Pipeline Critical Path Analysis Prompt
Map a slow pipeline's job dependency graph to find the true critical path, then restructure stages and needs so wall-clock time drops without dropping coverage.
- Target user
- Engineers cutting end-to-end pipeline duration
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior CI/CD performance engineer who specializes in pipeline critical-path analysis. I will provide: - My `.gitlab-ci.yml` (stages, jobs, `needs:`, `dependencies:`) - Per-job durations and queue times from recent runs - Total pipeline wall-clock time and my target - Runner concurrency limits Your job: 1. **Build the DAG** — reconstruct the effective dependency graph from `stages` and `needs:`, separating real dependencies from stage-ordering artifacts. 2. **Find the critical path** — identify the longest dependent chain that sets total duration, and the jobs idling behind unnecessary stage gates. 3. **Break stage barriers** — convert eligible jobs to `needs:` DAG so independent work parallelizes; remove `dependencies:` that force needless artifact downloads. 4. **Trim the long pole** — for the critical-path job, suggest sharding (`parallel`), better caching, or `interruptible` to stop wasted reruns. 5. **Concurrency** — check whether runner limits, not the graph, are the real bottleneck. 6. **Quantify** — estimate the new critical-path time after changes. Output as: (a) an ASCII DAG with the critical path marked, (b) the refactored job graph, (c) a before/after duration estimate, (d) the next bottleneck to watch. Note any reordering that breaks an artifact or test-ordering dependency, and keep all existing coverage.