Back to Cookbook
CI Speed Tune-Up
Cut pipeline time with caching, parallelism, and smarter triggers
Reduce CI wall-clock time by implementing dependency caching, parallelization/sharding, and filtering out unnecessary pipeline runs.
CommunitySubmitted by CommunityWork15 min
INGREDIENTS
🐙GitHub
PROMPT
Create a skill called "CI Speed Tune-Up". Ask me for: - CI provider (GitHub Actions/GitLab/etc.) and current config snippet - Typical runtimes per step (rough is OK) - Which suites must gate merges Output: - A prioritized optimization plan (top 5 changes) - A caching plan keyed on lockfiles - A parallelization/sharding plan - A "PR gate vs nightly" split recommendation
How It Works
This recipe audits a pipeline for the "big three" time sinks: repeated dependency installs,
serialized tests, and inefficient triggers.
Triggers
- CI takes "forever" (tens of minutes to hours)
- Developers avoid pushing because feedback is too slow
- CI costs spike due to redundant runs
Steps
- Identify the top time consumers (deps install, tests, packaging, uploads).
- Add dependency caching keyed on lockfiles.
- Parallelize/shard the slowest suites (unit/integration/e2e).
- Split PR-gating vs nightly:
- fast gates on PR,
- heavy suites nightly or on-demand.
- Validate cache correctness and avoid caching build outputs that cause staleness.
Expected Outcome
- Faster PR feedback and fewer "commit–push–wait" loops.
- Lower CI cost and higher developer throughput.
Example Inputs
- "Our pipeline is 45 minutes; most time is tests."
- "Dependency installs happen from scratch every run."
- "We need PR checks under 10 minutes."
Tips
- CI speed is feature delivery speed; treat it as a product.
Tags:#ci-cd#performance#developer-productivity#testing