Pipeline auto-cancellation of unneeded running jobs
Problem to Solve
Auto canceling redundant pipelines is great, but we're not going far enough. We still let
running pipelines finish, resulting in a lot of wasted time (compute and human). Some companies want pure bisectibility of their pipelines and want every permutation run individually, but many want to save compute costs on pipelines and this helps those users.
We should be more aggressive, and actively cancel pipelines that aren't dangerous to cancel.
- One path would be to assume any job that is a deploy would be dangerous to interrupt (as it may leave production in an indeterminate state), but other jobs are fully cancellable. Therefore, we should cancel any pipeline not currently running a deploy job.
- We would define a deploy job as any job that has an
environmentdefined, or a stage called 'deploy'. If people aren't using environments, we could consider another keyword to denote an unsafe job, but I hope that won't be necessary.
- We could consider certain branches (master) to be always built in sequence.
If https://gitlab.com/gitlab-org/gitlab-ce/issues/15310 is implemented, there is also a use case here for canceling a running "free" pipeline that has now been associated with an MR. We would need to be certain that the pipelines truly resolve to the same orchestration steps, though, since
only: merge-requests can result in different actual behavior (or this should be configurable what is preferred by each project.)
For teams that do not want this behavior, it should be possible to turn it off.