Getting a CI Pipeline Under Ten Minutes

Ten minutes is the line where a pipeline stops being a check and starts being an interruption. Under it, you wait. Over it, you go and do something else and lose the thread of what you were doing.

My pipeline runs lint and type-check, tests, a build and a deploy, and it used to take over 10 minutes end to end. It finishes in about 4 now. The two things that did it were running jobs at the same time instead of one after another, and caching dependencies so they are not installed from scratch on every run. I did not remove a single check to get there. On top of that there is a minute or two of waiting for a runner to pick the job up before any of my own work starts, and that part is not mine to optimise.

What changed, in order of how much it helped

1. Caching dependencies. Installing from scratch on every run is the single most repeated piece of work in any pipeline, and it is identical almost every time.
2. Running jobs in parallel. Lint, type-check and tests do not need each other's results, so queueing them was just a habit of writing the file top to bottom.
3. Accepting the runner wait. A minute or two passes before the job starts, and no amount of tuning my own steps touches it.

Where the time actually goes

Stage	Can it overlap?	Can it be cached?
Waiting for a runner	No, it is before your work	No
Installing dependencies	Yes, per job	Yes, and this is the big one
Lint and type-check	Yes, needs nothing else	Partly
Tests	Yes, needs nothing else	No
Build	Only after the code is known good	Partly
Deploy	No, it is last by definition	No

Why removing checks is the wrong first move

The fastest pipeline is one that does nothing, and the temptation when a run drags is to cut the step that feels least essential. That is usually the type-check or the slowest test file, which is to say the two things most likely to catch something.

Every minute I removed came from the same work being done more efficiently, not from less work being done. The checks that ran before still run. If you have cached and parallelised and it is still slow, then it is worth asking what a step is for, but not before.

The part you cannot fix

A minute or two of queueing sits in front of every run, and it is the one number I have no control over. It matters more than it sounds, because it applies to every push, including the one-line fix you are certain about. Four minutes of real work plus two of waiting is still a six-minute round trip for a typo.

That is the same reason a deploy is a bad place to put anything you need to happen quickly, which I found out the hard way when a flag I needed off was sitting behind one.

What to try first

Cache dependencies before anything else, because it is one block of configuration and it affects every job you have. Then look at your file and ask which steps are waiting on results they never use. Those two moves took me from over 10 minutes to about 4 with nothing removed, and anything after that is tuning.