Backend: Interruptible pipelines are not cancelled if created via web
Summary
We are using a self-hosted Gitlab server v12.9.2. We have a project that should launch a pipeline for building docker images. Interruptible pipelines are not canceled if created via web interface. There is a condition in config under which the last running pipeline should be canceled if a new copy is started:
default:
interruptible: true
I also made the rules for launching the pipeline at all:
workflow:
rules:
- if: $CI_MERGE_REQUEST_TITLE =~ /^WIP/
when: never
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: '$CI_PIPELINE_SOURCE == "web"'
Steps to reproduce
Run 2 pipelines sequentially through the web interface.
What is the current bug behavior?
When 2 pipelines are started sequentially via MR, everything works fine and the last but one launched is canceled. The issue is that when running 2 pipelines sequentially through the web interface, one of them is not canceled, although the rules are the same for them. That's why I consider this a bug.
What is the expected correct behavior?
When 2 pipelines run sequentially, the last but one launched should be canceled both when running via MR and when running via the web interface.
Proposed Solution(s)
- A Small Change: We could cancel pipelines on the same SHA if the pipeline source is also the same.
- A Large Change: We could ignore the SHA when canceling pipelines, and just cancel anything already running on the same ref. I've gone on the record before that I don't think people try to configure two different pipelines to run at the same time on the same ref (we already have separate logic to prevent cancellation of parent and child pipelines).
The team discused the options and decided to go with Removing where_not_sha but adding a source scope: