## For any feedback Please use this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/533802+ ## Overview Variables in CI/CD systems are critical to the efficacy of CI/CD workflows and are used as environment variables, context variables, secrets, matrix variables, and outputs. Today, in GitLab CI, when creating a pipeline, developers rely on CI variables to inject dynamic content into the pipeline. Using the new `spec:inputs` feature instead of CI variables provides developers with a more structured and flexible solution for injecting dynamic content at CI/CD job runtime. A more “structured approach” means better type checking and validation of inputs, reducing errors and simplifying the creation and maintenance of more complex CI/CD workflows. The value proposition of this feature may not necessarily be evident to new GitLab users or organizations with basic CI/CD workflows. However, for more advanced users or organizations with complex CI/CD workflows, this new approach will, over time, help organizations create CI/CD workflows that cost less to maintain as measured in developer hours and, by extension, result in increased developer efficiency for development teams. ## Problems to solve The problems described below are generally related to being able to specify inputs when triggering a pipeline. Today, when creating a pipeline we rely on CI variables to inject dynamic content to the pipeline. Using the new `spec:inputs` feature instead of CI variables make inputs more structured: * Only the specified inputs can be passed. * Inputs support basic types of validations. * Inputs lifecycle is scoped to the pipeline creation via text interpolation. Here below are some of the usages we could have with `inputs`. ## Iterations | Week 24-28 Feb - Prepare foundations | Progress | |--------------------------------------|----------| | https://gitlab.com/gitlab-org/gitlab/-/issues/519955+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519943+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/520831+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519944+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519950+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519956+s | :white_check_mark: | | Week 3-7 Mar - Pass inputs to pipeline creation | Progress | |-------------------------------------------------|----------| | https://gitlab.com/gitlab-org/gitlab/-/issues/520586+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519958+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519960+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519963+s | :white_check_mark: | | Week 10-15 Mar - Finalize features using inputs | Progress | |-------------------------------------------------|----------| | https://gitlab.com/gitlab-org/gitlab/-/issues/520593+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/519961+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/520075+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/521003+s | :white_check_mark: | | Week 17-21 Mar - Internal rollout and readiness review | Progress | |--------------------------------------------------------|----------| | https://gitlab.com/gitlab-org/gitlab/-/issues/520594+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/525504+s | 80% | | https://gitlab.com/gitlab-org/gitlab/-/issues/520290+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/520108+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/524407+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/524839+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/526030+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/526032+s | :white_check_mark: | | Week 24-28 Mar - Non-blocking tech debt | Progress | |-----------------------------------------|----------| | https://gitlab.com/gitlab-org/gitlab/-/issues/519952+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/521201+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/520985+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/523238+s | :white_check_mark: | | https://gitlab.com/gitlab-org/gitlab/-/issues/525088+s | :white_check_mark: | ### Feature flag: [ci_inputs_for_pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/520290) ### Problem 1: Inputs are better than pre-filled variables Rather than using [prefill CI variables](https://docs.gitlab.com/ee/ci/pipelines/index.html#prefill-variables-in-manual-pipelines) we should be using `inputs` as a safer alternative. The prefill variables feature predates `inputs` and allows users to define CI variables that are evaluated throughout the whole pipeline lifecycle. Prefill variables design also [overlaps with `inputs`](https://docs.gitlab.com/ee/ci/pipelines/index.html#configure-a-list-of-selectable-prefilled-variable-values) (like the ability to specify options) but it doesn't inherits all the benefits of `inputs`. Rather than using prefilled variables we should allow a pipeline to take explicit inputs: * In the "Run pipeline" form we should take inputs as specified in the `spec:inputs` of the `.gitlab-ci.yml` file. Following the schema from `spec:inputs` we could render specific UI form widgets (selectbox, numeric field, text field, etc.). * Allow REST API to take `inputs` as parameter that is passed to the pipeline creation logic. ### Problem 2: Trigger downstream pipeline with inputs > if we write a golden template that uses `spec:input` rather than variables, that definition can not be used in a triggered job, keeping us in the land of variables, with their relative deficiencies relative to inputs. Downstream pipelines are often designed as CI services. For example, take my repository and run some tests on it. This means that they almost always require inputs. Rather than using CI variables we should make the downstream pipeline accept an explicit list of input parameters: ```yaml # file: .gitlab-ci.yml # project: myorg/static-analysis spec: inputs: project: --- scan_project: script: scan-project --path=$[[ inputs.project ]] ``` ```yaml # .gitlab-ci.yml static_analysis: trigger: - project: myorg/static-analysis inputs: project: $CI_PROJECT_PATH ``` ### Problem 3: Trigger child pipeline with inputs **This may be already supported today** as we allow it with `include` syntax. Allow child pipelines to be composed of templates/components using inputs. ```yaml microservice_a: trigger: include: - project: myorg/static-analysis inputs: project: $CI_PROJECT_PATH - local: child.yml inputs: test: foo ``` ## Proposal 1. Enable `.gitlab-ci.yml` to contain `spec:inputs` section. 2. Allow `Ci::CreatePipelineService` to take `inputs` and pass them to the YAML processing. 3. Enable pipeline creation endpoints to use inputs (UI form, REST API, GraphQL, pipeline schedules, etc.) 4. Deprecate use of pre-fill variables in favour of inputs.Details ## Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Allison (Application Ops)](https://about.gitlab.com/handbook/product/personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Amy (Application Security Engineer)](https://about.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Isaac (Infrastructure Engineer)](https://about.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/product/personas/#alex-security-operations-engineer)