Introduce `{}` to indicate `null` in needs: (and possibly also for stage:)
When using pipeline components, we may want to have control over needs:
from the outside. This is especially true when not relying completely on DAG. Also, a component user may not have DAG setup etc or may not want/have the stage test
.
E.g.
spec:
inputs:
needs:
description: 'Explicitly set needs (['need', 'need']). When left empty, rely on stage dependencies.'
default: '{}'
---
stages:
- lint
- build
- test
- deploy
job:
needs: $[[ inputs.needs ]]
stage: deploy
(pardon my abuse of global stages in the component)
What the user wants/expects, is that to run this component after all previous stages have completed. The traditional pipeline flow. Because a component cannot know which needs there are from previous stages of course. We can let the user define these, as a work-around only, but ideally the component should work 'out of the box'.
The following is impossible with the current limitations. Ideally, we'd set needs
to null
. This would work, if not that defaults: null
is not valid, and default: 'null'
is not quite what we expect of course. The first fails on the fact that defaults
is not a string, the second fails as 'null'
is not a hash or an array.
Currently, we also often use {}
to 'unset' items in the gitlab yaml, and I propose we continue this trend for needs.
If needs where to accept {}
, which should be interpreted as null
, we actually 'undefine' needs, and rely on stages
again to set the build order. Obviously, this does require the user to have the correct stages, but that is probably more convenient for them, then to rebuild their entire pipeline to properly have 'needs' (or hack their pipeline to introduce a fake stage, which can then be used to 'need' upon.
All of the above works also for stage:
for the same reason ...