In a GitLab CI/CD component, what does a spec:inputs header give you that configuring an included template through global variables does not?

## The problem with variable-configured templates The classic GitLab shared template takes its configuration from CI/CD variables: ```yaml # in the template scan: script: - scanner run --fail-on "$SCAN_SEVERITY" ``` The consumer sets `SCAN_SEVERITY` in their `variables:` block, in project settings, or not at all. Every failure mode here is silent: a typo gives an empty string; a value the scanner does not accept is discovered when the job runs, minutes later; the variable is global, so it also lands in every unrelated job's environment; and including the template twice with different settings is impossible, because there is one variable namespace. ## What `spec:inputs` changes A component or template file may begin with a **spec header**, a separate YAML document ended by `---`: ```yaml spec: inputs: stage: default: test description: Stage the scan job runs in severity: type: string default: high options: [low, medium, high] --- scan: stage: $[[ inputs.stage ]] script: - scanner run --fail-on $[[ inputs.severity ]] ``` The consumer supplies values on the include itself: ```yaml include: - component: $CI_SERVER_FQDN/platform/ci-components/[email protected] inputs: severity: medium ``` Five differences matter. **It is interpolation, not a variable.** `$[[ inputs.severity ]]` is substituted into the YAML text *before* GitLab parses the configuration. That is why an input can decide a stage name, a job name, an `image:`, or whether a whole block exists — places where a `$VARIABLE` would be meaningless because the value is needed at configuration time, not at runtime. Note the distinct syntax: `$[[ ... ]]` is interpolation, `$VAR` is a runtime variable, and they are resolved at different moments. **It is validated.** `type` (string, number, boolean, and array in newer versions), `options` for an enumeration, and `regex` for a string pattern are all checked while the pipeline is being created. A bad value produces a configuration error on the pipeline page — no jobs start — instead of a job that fails ten minutes in. **It has declared defaults and required inputs.** An input with no `default` is mandatory: omit it and pipeline creation fails naming the input. That turns "which variables does this template need?" from tribal knowledge into a machine-checked contract, and `description` makes the file self-documenting. **It is scoped to the include.** Two includes of the same component with different inputs are independent, because nothing is written into the global variable namespace. Variable-configured templates cannot do this at all. **It composes with versioning.** `include:component` addresses a component published in the project's `templates/` directory and released to the CI/CD catalog, pinned by version: `@1.2.0` for an exact release, a branch or commit for development, or `@~latest` for the newest release. A component's inputs are therefore versioned along with its behaviour, which is what makes a breaking change to a template a *semver* event rather than a surprise. ## Inputs are not exclusive to components A common misconception: `inputs:` also works with `include:local`, `include:project` and `include:remote` — any included file that declares a `spec:` header can be given `inputs:`. Components add the catalog, the versioning scheme and a discoverable published surface; the parameter mechanism itself is shared. ## Where it still bites Interpolation happens before parsing, so an input value containing YAML-significant characters can change the shape of the document — quote where it matters. Interpolation also only applies inside the file that declared the spec; you cannot reach `inputs` from an unrelated file. And because everything is resolved at pipeline creation, an input cannot depend on anything a job computes; that remains the job of `rules:` or a child pipeline. ## The interview shape Asked as "how do you make a shared template configurable without a wall of global variables?", the expected answer is: declare a spec header with typed inputs, interpolate them with `$[[ inputs.x ]]`, publish the file as a versioned component, and let consumers pass `inputs:` on the include. The follow-up is usually about migration — you can add a spec header to an existing template and keep reading the old variables for a release or two while consumers move.