Auto-cancel redundant, pending pipelines not working as expected

GitLab CI/CD
1

We have several projects in our self-managed GitLab (13.6.3-ee) that all contribute toward our product, and I’m trying to create a pipeline that will avoid duplicate builds and deploys when changes are pushed to several projects within the same time frame. Each project’s gitlab-ci.yaml file triggers a pipeline in a single project that has an action similar to the following:

checkwait:
  interruptible: true
  script:
    - echo "Part 1"

postwait:
  interruptible: true
  rules:
    - when: on_success
      when: delayed
      start_in: 5 minutes
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Job started"

My expectation was that the first time the pipeline was triggered, it would execute the “checkwait” job and then delay the “postwait” job for the specified 5 minutes. Because Auto-cancel redundant, pending pipelines is true, subsequent times the pipeline is triggered, I expected either the first job would be cancelled or the second one would when it was created.

The way it actually behaves is to execute the “checkwait” job and put the “postwait” job into delayed status in both cases.

Am I misunderstanding how this is supposed to work? Is there another way I can get the results I’m looking for? Any help would be appreciated.

1 Like
2

Hi @andyman

This is interesting! I see from the docs that a job can be interrupted if it is:

  1. Pending
  2. Started

but the docs do not say what will happen if the pipeline is in a delayed state.

I wonder what would happen if you did something like this:

stages:
  - checkwait
  - wait
  - postwait

checkwait:
  interruptible: true
  script:
    - echo "Part 1"

wait:
  interruptible: true
  script:
    - sleep $(expr 60 \* 5)    

postwait:
  interruptible: true
  rules:
    - when: on_success
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Job started"
3

Yes I saw the docs, but I was hoping that “pending” in that case meant either delayed or pending like it does in English!

I gave your idea a try, but I think you had your stages syntax confused, it didn’t like it. I changed it to this:

stages:
  - checkwait
  - wait
  - postwait

checkwait:
  stage: checkwait
  interruptible: true
  script:
    - echo "Part 1"

wait:
  stage: wait
  interruptible: true
  script:
    - sleep $(expr 60 \* 5)    

postwait:
  stage: postwait
  interruptible: true
  rules:
    - when: on_success
  variables:
    GIT_STRATEGY: none
  script:
    - echo "Job started"

I started three pipelines in a row and they just ran sequentially:
Pipeline 1: “checkwait” started and went immediately to “wait” running
Pipeline 2: “checkwait” was pending until Pipeline 1 finished
Pipeline 3: same as above.

Thanks for the reply though, it’s given me some ideas about how to use stages, which I will try out tomorrow. Will post if I find a solution.

4

Note that pipelines started via the web interface (“Run Pipeline”) are not cancelled at the moment.
See this issue: Interruptible pipelines are not cancelled if created via web (#287780) · Issues · GitLab.org / GitLab · GitLab

So you need to do some commits to test the cancellation.
I also ran into this and when I then made a commit, the previous pipeline was cancelled also while it was delayed.

5

Thanks, Jochen, this was exactly the problem. I hate when the error is in the test and not the solution, makes it much harder to debug!