Thoughts on spec.inputs and components

I’ve been working a bit with components and spec.inputs.

Bugs

First, some apparent bugs I’ve noticed.

  1. regex doesn’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.
  2. 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.
  3. You can’t use inputs inside a !reference, i.e. !reference [ .scripts, $[[ inputs.my-script ]] ]

Versioning

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.

Inputs

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 rules.changes.

Functions

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 ]]

1 Like

Thanks for sharing. I have linked this forum topic into the CI/CD components beta feedback issue. CI/CD Catalog: Feedback issue about inputs, components and catalog (#407556) · Issues · GitLab.org / GitLab · GitLab I’m trying to answer some immediate questions, but would encourage you to share your thoughts in the feedback issue, too, to increase visibility and engagement.

  1. 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.

This is tracked in Backend: Pipeline boolean and number include input types are not preserved downstream (#434826) · Issues · GitLab.org / GitLab · GitLab for Inputs GA (epic: CI Catalog - Inputs Validations - go to GA (&12464) · Epics · GitLab.org · GitLab)

  1. You can’t use inputs inside a !reference, i.e. !reference [ .scripts, $[[ inputs.my-script ]] ]

Not yet supported, tracked in Backend: Support inputs with !reference (#424481) · Issues · GitLab.org / GitLab · GitLab and also discussed in this thread Backend: Error messages for CI/CD component inputs are not helpful (interpolation) (#434069) · Issues · GitLab.org / GitLab · GitLab

It would also be nice to have $[[ version ]] which would resolve to whichever version or reference is being used.

I think this feedback thread can be helpful: CI/CD Catalog: Feedback issue about inputs, components and catalog (#407556) · Issues · GitLab.org / GitLab · GitLab

Thanks! Looks like a lot of good progress is being made.

On the question of “to v or not to v” as a prefix to the version number, I feel it should definitely be supported. I’m used to working with npm and the npm version command will generate a tag with the v prefix, so it’s what I’m used to and I’d like to have that consistent with node projects. I even added a package.json to my component just for the convenience of using npm version along with my usual preversion, version, and postversion scripts.

I was a bit surprised somebody thought passing booleans/numbers on would be an unusual pattern. I have ideas for several components that would be reused within other components, all of which would require such things.

Looking forward to future release notes!

Thanks :slight_smile: Please add your thoughts into the feedback issue too, or create a feature proposal issue, so that our engineers and product managers can see and discuss :slight_smile:

@dnsmichi - is there an issue/bug to track the fact that spec.inputs.input_name.regex does not seem to work at all?

that spec.inputs.input_name.regex does not seem to work at all?

I’m not aware of an issue, but also hard to tell without more context on your problem.

Please feel free to create an issue, and add details to reproduce the problem. You can also share your feedback in the issue CI/CD Catalog: Feedback issue about inputs, components and catalog (#407556) · Issues · GitLab.org / GitLab · GitLab if unsure whether it is a bug.

Okie doke, i’ll create a new issue will ful details, just didn’t want to duplicate. When i followed the convo through seemed like it was felt most the issues raised above were being tracked, but couldn’t find one about the regex, despite searching explicitly.

No worries on duplicates, better create your feedback/idea/bug report async, and let others link existing references if existing. There are also automation and triage bots in place that help engineering teams with reviews.

Finally got around to raising the issue, in the preparation i realised the problem is less the actual regex feature but actually the docs surrounding it. If anyone else finds themselves unable to use the feature see details here:

1 Like