Empty needs (needs: []) cannot be applied via rules:needs:
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Hello,
I am trying to reset a job's needs using rules:needs: [] of a job having an already defined needs (with some previous job needed).
The documentation says that it should "sets the job needs to none when the specific condition is met" (c.f. the documentation of rules:needs).
However, when I tried to use rules:needs: [], the job's needs are not setted to none.
Note: I'm not sure what this specific condition is.
Steps to reproduce
- create a
.gitlab-ci.yml - add a A job to be needed by other jobs
- add a B job, which will need the job B with
needs, and have arules:needssetted to[]to reset it's needs in one rule
Example Project
Here is the .gitlab-ci.yml I used to reset the job's needs
stages:
- prepare
- test
needed job:
stage: prepare
rules:
- when: manual
- when: on_success
script:
- echo "ok"
# when the pipeline is launched, this job should be runnable manually,
# but it does not seems to be (the job is waiting for the previous needed one)
override needs in rule ([]):
stage: test
needs:
- job: needed job
rules:
- when: manual
needs: []
- when: on_success
script:
- echo "ok"
# trying to use null instead of [] gives the same results
override needs in rule (null):
stage: test
needs:
- job: needed job
rules:
- when: manual
needs: null
- when: on_success
script:
- echo "ok"
# overriding with a non-existing job seems to give the expected result
# (i.e. the job can be runned manually, and is not waiting for the previously needed job)
override needs in rule (non existing job):
stage: test
needs:
- job: needed job
rules:
- when: manual
needs:
- job: non-existing-job
optional: true
- when: on_success
script:
- echo "ok"
What is the current bug behavior?
The job with the configuration rules:needs: [] still waits for the job previously needed configured in needs.
What is the expected correct behavior?
The job does not wait for the previously needed job configured in needs.
Output of checks
Possible fixes
Using a "fake" non-existing job name can be used as a workaround to reset a job's needs to none
override needs in rule (non existing job):
stage: test
needs:
- job: needed job
rules:
- when: manual
needs:
- job: non-existing-job
optional: true
- when: on_success
script:
- echo "ok"
Others
Related to #31581 (closed)
Might be described here #417246 (closed) as the expected behavior, but I'm not sure why given the gitlab's documentation