Speed up Gitlab CI by using fewer steps in the pipeline

When I was writing on how to do Flutter test reports in Gitlab Ci I noticed my pipeline was split into three steps:

• linting
• test run
• coverage report

When I first set this up, it felt “prettier” to me. They were all independent and if one step failed I could easily see which.

However, writing the post on test reports the thought struck me, won’t each step require the container to initialize? Won’t this take time?

It definitely looks like pulling down the container, even if from the cache, indeed slow things down:

So, today I can share the outcome of testing this for real.

Input jobs

I compared two identical script runs, one with the original three job pipeline and one with all three jobs joined into a single step.

Below you will find the raw Gitlab CI YAML files for reference.

The original three-stage file