rules:if causes two pipelines to be run on MRs and jobs to be missing
rules:if when, after force pushing to MR, instead of 1 pipeline, 2 are run, one regular and one detached MR. To make things worse, the detached pipeline is mutilated, jobs that have no
rules defined on them are missing.
This bug breaks MRs' pipelines when
rules: are used.
rules: rather hard to apply in complex pipelines with dependencies. Imagine there's a deploy job, that can be triggered manually (
when: manual) on every pipeline (think of: deploy to demo lab) and should be triggered on a scheduled nightly pipeline (think of: bring demo lab up to speed) always (
when: on_success). This deploy job depends on a build job, that has to run on every pipeline, a job that does not need
Instead I'll end up with duplicating jobs and toying with
only/except. Also I guess, spamming with
rules: could also solve this issue.
Steps to reproduce
ruleson at least one job and at least one job without it
- optionally: to a job with
rules, add a
dependsto make it depend on a job without
- Commit some changes
- Make MR
- Observe pipelines in MR
What is the current bug behavior?
When there's a
rules: block present in .gitlab-ci.yml block, two pipelines are run, one regular, and one detached on top of it. The detached features only jobs with
rules and nothing else, leading to pipeline failing on unmet dependencies.
rules: only change
on_success, not the actual presence of any job.
Everything is exposed in my sample repo: https://gitlab.com/falxcerebri/gitlab-ci-rules-bug/
What is the expected correct behavior?
- There should be just one pipeline in Merge Request, since there's no
only:/except: merge_requestused anywhere
- Even if 2 pipelines are necessary due some technical reasons, the resulting detached pipeline should consist of all jobs, not only these with
Relevant logs and/or screenshots
Output of checks
Unfortunately I have no idea. I guess this may be somewhat linked with detached pipeline settings but that's just a wild guess.