<!-- ## Implementation Issue To-Do list (_NOTE: This section can be removed when the issue is ready for creation_) - [ ] Ensure that issue title is concise yet descriptive - [ ] Add `Frontend :` or `Backend: ` per group [naming conventions](https://about.gitlab.com/handbook/engineering/development/ops/verify/pipeline-authoring/#splitting-issues) - [ ] Ensure the issue containing the feature or change proposal and related discussions is linked as related to this implementation issue. - [ ] Aside from default labeling, please make sure to include relevant labels for `type::`, `workflow::`, and `~frontend`/`~backend` labeling. - [ ] Issues with user-facing changes should include the `~UX` label. --> ## Problem As a user, I want to ensure that the input I enter when using a component meets the correct format and type so that I can avoid errors or unexpected results when running a CI pipeline ## Proposal Related to https://gitlab.com/gitlab-org/gitlab/-/issues/390458, by adding an optional subkey `type:` (https://gitlab.com/gitlab-org/gitlab/-/issues/390458) and `regex:`, we will improve the quality of the data and prevent potential errors, while making the user experience smoother and more reliable. ```yaml spec: inputs: environment: type: string/boolean/number # optional regex: /^gitlab.com/ # optional ``` when parsing `spec: input` we should add a data type validation, and in case of a wrong input we should present the user with the error `Wrong <variable name> input type expected string/boolean/number` ## Additional details <!-- _NOTE: If the issue has addressed all of these questions, this separate section can be removed._ --> Some relevant technical details, if applicable, such as: - Does this need a ~"feature flag"? - Does there need to be an associated ~"instrumentation" issue created related to this work? - Is there an example response showing the data structure that should be returned (new endpoints only)? - What permissions should be used? - Is this EE or CE? - [ ] EE - [ ] CE - Additional comments: <!-- ## Documentation _NOTE: This section is optional, but can be used for easy access to any relevant documentation URLs._ --> ## Links/References