Beginner · CI

Design a CI pipeline for a service that people will actually read

A team has one CI job that runs for 38 minutes and fails about a third of the time for reasons unrelated to the change. People merge without waiting. Redesign the pipeline. You are told the goal is "make CI faster".

The fix that looks right

Trap

Cutting the runtime by turning off the end-to-end suite on pull requests and moving it to a nightly job. The pipeline is now fast and the number everyone was watching improved — but the failures have simply moved to a run nobody is blocked by, discovered the next morning against a batch of twenty merged changes, so every failure now needs a bisect to attribute. You traded fast feedback on one change for slow feedback on twenty. Moving a check later is only safe when something else catches that class of failure earlier.