Skip to content

delayed and manual jobs with DAG are not skipped even they need a failed job

Summary

In the example below, the build is failed, then the test is skipped. The deploy should also be skipped, because it needs a failed job. This bug was fixed for when: on_success jobs (#31526 (closed)), but for when: delayed and when: manual were not considered in that fix.

.gitlab-ci.yml

image: alpine

build:
  stage: build
  script: exit 1

test:
  stage: test
  script: exit 0

deploy:
  stage: deploy
  needs: [build, test]
  when: delayed
  start_in: 5 seconds
  script: exit 0

Pipeline:

Screen_Shot_2020-12-12_at_19.49.17

old issue description When running two jobs, where the second depends on the first, we normally get a canceled event for the second on the failure of the first. This is normal and expected. We can even make this very explicit by using the needs keyword.

However, when we use rules to make this second job only work on certain tags, and make it delayed; the rules will make the job always be added to the pipeline, regardless of the previous outcomes. E.g. on_success is no longer honored.

This code existed 'pre-rules' for me as well, with except/only and was working as expected.

Steps to reproduce

build:
  stage: build
  script: exit 1

test:
  stage: test
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v\d+\.\d+(\.\d+)+$/'
      when: delayed
      start_in: 2 minutes
  needs:
    - job: build
      artifacts: true
  script:
    - echo "Test success"

Here, we expect the pipeline to not be allowed to be triggered on failure of execution of the 'build' step, however the timer happily ticks and on expiry runs the job.

Example Project

What is the current bug behavior?

The job 'deploy' runs, regardless of the state of 'build'

What is the expected correct behavior?

If 'build' is canceled or fails, 'deploy' should be skipped same as test.

Relevant logs and/or screenshots

image

Output of checks

This bug happens on GitLab.com

Possible fixes

It seems like with the new rules syntax ignores the 'on_success' behavior when doing delayed jobs, e.g. 'delayed' really means 'delayed_always'. If delayed should NOT do do this, then a new rule, delayed_on_success, which only runs when the previous job was successful, may need to be added.

Adding the same condition build.scheduling_type_dag? for manual and delayed conditions.

Edited by Furkan Ayhan