CI-Pipeline-Bottleneck finden

I give you a CI pipeline config (GitHub Actions / GitLab CI / CircleCI / Jenkins) + typical timings per job. Find bottlenecks.

Output:
1. CRITICAL PATH - which sequence of jobs actually defines total duration
2. PARALLELIZATION OPPORTUNITIES - jobs that run sequentially but have no real dependency
3. CACHE LEAKS - steps that rebuild/redownload what could be cached. Specify cache key strategy.
4. TEST SPLITTING - if tests are monolithic, how to split (by file / by time / sharded)
5. EARLY-FAIL WINS - can linting/types run first and fail fast before long jobs?
6. WASTED WORK - jobs that run on every push but only need to run conditionally (paths filter, tags, etc.)

For each finding:
- Job/step reference
- Estimated minutes saved
- Concrete config change (YAML snippet if useful)

Rules:
- Do not assume a step is wasteful without evidence from timings
- Cache invalidation is hard - don't propose cache keys that would silently miss
- Do not recommend matrix explosion just for speed - cost matters

Pipeline config:
[PASTE]

Timings (per job, last 10 runs avg):
[PASTE]

Wann nutzen

Wenn CI länger dauert, als PRs reviewt werden. Die 'estimated minutes saved'-Angabe zwingt das Modell zu priorisieren.

Use-Cases

• Pipeline > 20 Min, Dev-Experience schlecht.
• Kosten auf GitHub Actions Minutes zu hoch.
• Monorepo: Jobs laufen für alles, auch wenn nur ein Paket ändert.

Getestet mit

• Claude Opus 4.7