I’ve been working a bit with components and
First, some apparent bugs I’ve noticed.
regexdoesn’t seem to work at all even with the simplest patterns. I had hoped to test if the pattern was tested against the value with variables expanded, but I couldn’t even get it to validate a regular value with no variables in it.
- boolean inputs can’t be passed on to another template. When you put
$[[ inputs.some-boolean ]]as the value for an input it will fail validation. I didn’t try with a number, but I expect it will be the same there.
- You can’t use inputs inside a !reference, i.e.
!reference [ .scripts, $[[ inputs.my-script ]] ]
It’s nice that you’re encouraging semver versioning, but at the moment you’re missing a lot of the advantages of it. For example I should be able to specify versions I want much like you can in an npm package.json. If I set my version as
@^1.0.0 it should pick up anything in v1, but not anything in v2. As it is I’m limited to either a very specific release or the latest one. This means I either have to update every single project every time I fix a typo, or potentially introduce breaking changes to everything all at once.
It would also be nice to have
$[[ version ]] which would resolve to whichever version or reference is being used. One thing I wanted to do was download some files from the component repository, and it would be handy to be able to pass that in to the API archive call. At the moment I’m doing this by providing a
version input that gets updated on every release. The catch with that is if somebody is using a non version reference (i.e. a branch) they have to remember to update the input as well as the component version. It would also be handy to have that just so it could be displayed somewhere so that people know exactly which version of the component is running.
It would be useful to default the value of one input to the same as another. For example a component that creates two jobs that are by default in the same stage but perhaps in some situations you want the second job in another stage.
An array input type could be useful, for example to pass in a list of files that may be used in
A couple additional functions I thought would be useful:
match regex - would return the matching portion, or if a capture group is present what is in the group. e.g.
$[[ inputs.version | expand_vars | match /^v\d+/ ]]
replace regex-or-string string - replace one value in the string with another, e.g.
$[[ inputs.my-string | expand_vars | replace foo bar ]]