[go: up one dir, main page]
Skip to content

Support inputs for pipelines

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.

Problem 1: Inputs are better than pre-filled variables

Rather than using prefill CI variables 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 (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:

# file: .gitlab-ci.yml
# project: myorg/static-analysis
spec:
  inputs:
    project:
---
scan_project:
  script: scan-project --path=$[[ inputs.project ]]
# .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.

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

Edited by Fabio Pitino