Jobs unexpectedly ignored in Merge Request pipelines
I encountered an issue with the execution of some simple jobs in Merge Request pipelines, using the Docker executor. It is possible that this issue arises from my misunderstanding on how and when pipelines should run.
The following .gitlab-ci.yml code allows to reproduce the problem.
stages:
- stage1
- stage2
default:
image: alpine:latest
variables:
RUN_JOB1: "true"
# Change this from true to false and see how this inversely affects job2 as well!
job1:
stage: stage1
rules:
- if: $RUN_JOB1 == "true"
script:
- export
job2: # this job should always start, but it does not if RUN_JOB1 is true
stage: stage2
script:
- export
To reproduce:
- Create a test project
- Add the above
.gitlab-ci.ymlfile in a separate branch - open a Merge Request for said branch
- Check the generated pipeline: with the above setting, only
job1starts, but notjob2 - If
$RUN_THIS_JOB == "false"is set, the behaviour is:job2starts (although MR pipelines should only start if explicitly allowed to?), but notjob1 - Repeat the above for a branch pipeline (not a Merge Request pipeline): with the same settings, the behaviour is different: both
job1andjob2are queued if$RUN_THIS_JOB == "true".
Other things to note:
- I have not tested with other Executors, as I do not have any at my disposal right now.
- GitLab version: GitLab Community Edition 15.3.3
- The runner config (
config.toml) is:
concurrent = 1
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "doky-test-1"
url = "https://gitlab.myinstance.com"
token = "[SECRET_TOKEN]"
executor = "docker"
shell = "bash"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
[runners.cache.azure]
[runners.docker]
tls_verify = false
image = "alpine:latest"
privileged = false
disable_entrypoint_overwrite = false
oom_kill_disable = false
disable_cache = false
volumes = ["/cache"]
shm_size = 0
Edited by Adriano Fantini