Expose Included Pipeline Inputs to the Parent Pipeline's Run Pipeline UI

Release notes

GitLab CI/CD inputs from included pipelines are automatically exposed to the parent pipeline's "Run Pipeline" UI, enabling centralized management of shared pipeline configurations without duplicating input specifications across parent pipelines.

Problem to solve

As a DevOps Engineer, I want inputs defined in shared/included pipelines to be automatically exposed in the parent pipeline's "Run Pipeline" UI, so I can maintain shared pipeline configurations in one place without having to duplicate input specifications in every parent pipeline that includes them.

Current behavior:

When using variables: in a shared pipeline, these variables are automatically exposed in the "Run Pipeline" UI of any parent pipeline that includes it. Users can set values for these variables when manually triggering the pipeline. When using spec:inputs the inputs are not exposed to the parent pipeline's Run Pipeline UI.

Desired behavior:

When using spec:inputs: in a shared pipeline, these inputs should similarly be exposed in the "Run Pipeline" UI of parent pipelines, allowing users to provide values without having to duplicate the entire spec:inputs: section in every parent pipeline.

Business impact:

Organizations with shared pipeline registries cannot adopt CI inputs because it creates a maintenance burden - every change to input specifications in the shared pipeline would require updating all parent pipelines that include it. This defeats the purpose of centralized, reusable pipeline configurations. Intended users

User experience goal

When a user clicks "Run Pipeline" for a pipeline that includes shared pipelines with defined inputs, they should be able to see and set values for those inputs in the UI without having to duplicate the input specifications in the parent pipeline configuration. The workflow should match the existing behavior of variables: - where variables from included pipelines are automatically exposed to parent pipelines.

Proposal

Current Workaround (Undesirable): 

# Parent pipeline (.gitlab-ci.yml)

spec:
  inputs:
    TERRAFORM_PATH:
      type: string
      description: The folder path to the terraform configuration
    TERRAFORM_ACTION:
      type: string
      description: The action to perform on the Terraform configuration
    # ... must duplicate ALL inputs from shared pipeline

include:
  - project: group/gitlab-pipeline-registry/terraform-operations-pipeline
    file: terraform-operations-pipeline.gitlab-ci.yml
    ref: 3.4.0
    inputs:
      TERRAFORM_PATH: $[[ inputs.TERRAFORM_PATH ]]
      TERRAFORM_ACTION: $[[ inputs.TERRAFORM_ACTION ]]
      # ... must pass through ALL inputs

Proposed Solution - Option 1 (Automatic Exposure): 

# Parent pipeline (.gitlab-ci.yml)

include:
  - project: group/gitlab-pipeline-registry/terraform-operations-pipeline
    file: terraform-operations-pipeline.gitlab-ci.yml
    ref: 3.4.0
    # No spec:inputs needed in parent - automatically inherited
# Shared pipeline (terraform-operations-pipeline.gitlab-ci.yml)
spec:
  inputs:
    TERRAFORM_PATH:
      type: string
      description: The folder path to the terraform configuration
    TERRAFORM_ACTION:
      type: string
      description: The action to perform on the Terraform configuration

When the parent pipeline's "Run Pipeline" UI is opened, it automatically shows all inputs from included pipelines, allowing users to set their values.

Proposed Solution - Option 2 (Explicit Opt-in): 

# Parent pipeline (.gitlab-ci.yml)
include:
  - project: group/gitlab-pipeline-registry/terraform-operations-pipeline
    file: terraform-operations-pipeline.gitlab-ci.yml
    ref: 3.4.0
    expose_inputs: true  # Explicit flag to expose inputs to parent UI

User Journey

  • Platform Engineer maintains a shared Terraform operations pipeline in a central GitLab project
  • The shared pipeline defines spec:inputs: with parameters like TERRAFORM_PATH, TERRAFORM_ACTION, TERRAFORM_ENVIRONMENT
  • Multiple application teams include this shared pipeline in their .gitlab-ci.yml files
  • Developer on Application Team A needs to run a Terraform deployment
  • Developer clicks "Run Pipeline" in GitLab UI
  • The "Run Pipeline" form automatically displays the inputs from the included shared pipeline
  • Developer fills in the necessary values (e.g., TERRAFORM_ACTION: "apply", TERRAFORM_ENVIRONMENT: "prd")
  • Pipeline runs with the provided input values passed to the shared pipeline
  • Platform Engineer updates the shared pipeline to add a new input (e.g., TERRAFORM_WORKSPACE)
  • All parent pipelines automatically show the new input in their "Run Pipeline" UI without any changes needed

Further details

Use Case:

Organizations like us maintain centralized pipeline registries with shared, reusable pipelines for common tasks (Terraform operations, deployments, security scans, etc.). These shared pipelines currently use variables: with descriptions to provide a UI for users to input values when manually triggering pipelines. The transition to spec:inputs: is desirable because inputs provide:

  • Type safety (string, boolean, number)
  • Required vs optional designation
  • Default values
  • Better validation
  • Option lists for constrained values

However, the current implementation prevents adoption because inputs don't inherit to parent pipelines like variables do.

Benefits:

  • Reduced duplication: Maintain input specifications in one place (the shared pipeline)
  • Easier maintenance: Updates to input specifications automatically propagate to all consumers
  • Consistency: All pipelines using the shared pipeline get the same input interface
  • Adoption of inputs: Organizations can migrate from variables to inputs without losing functionality
  • Simplified parent pipelines: Parent .gitlab-ci.yml files remain minimal - just the include statement

Current Workaround Impact:

The requirement to duplicate all input specifications in parent pipelines:

  • Creates maintenance burden (every input change requires updating all parent pipelines)
  • Introduces risk of drift (parent and child input specs getting out of sync)
  • Discourages adoption of inputs feature
  • Negates benefits of shared pipeline registries
  • Forces continued use of less robust variables: approach

Real-World Example:

We have a shared Terraform operations pipeline with 5 inputs (TERRAFORM_PATH, TERRAFORM_ACTION, TERRAFORM_ENVIRONMENT, TERRAFORM_STATE_LOCK_ID, PIPELINE_DEBUG). This pipeline is included in dozens of application pipelines. Any change to these inputs currently requires updating dozens of parent pipelines, which is not scalable.

Related Documentation:

Edited by 🤖 GitLab Bot 🤖