Interlock - Dynamic CI Job Parameters (Job inputs) (#18551) · Epics · Epics · GitLab.org

Interlock - Dynamic CI Job Parameters (Job inputs)

<details> ## PMM Summary content: **Feature title**: Dynamic CI Job Parameters **Value Proposition**: Enable developers to set parameters for individual manual jobs during pipeline execution—eliminating costly full pipeline re-runs and reducing deployment errors for dynamic, real-time CI/CD workflows. **Primary Target Audience:** - Enterprise DevOps teams - Jenkins migration prospects - Complex pipeline users **Marketing Channels:** - Release Post (must-have) - Customer Success - customer outreach; - Blog Post (optional) - other? **Key Benefits:** Development Teams: - Make real-time decisions based on earlier job outputs or changing external conditions - Avoid cumbersome, error-prone workarounds when parameters are unknown at pipeline start - Reduce workflow disruptions caused by needing to modify parameters mid-pipeline - Faster iteration cycles by parameterizing single jobs instead of re-running entire pipelines For Enterprise Operations: - Lower CI/CD pipeline compute costs by eliminating expensive full pipeline re-runs for simple parameter changes - Reduce deployment errors from manual workarounds - Critical capability for Jenkins consolidation - Addresses workflow patterns common in complex enterprise CI/CD operations **Release Post Content Draft** ## Release Notes Dynamic CI Job Parameters GitLab now enables developers to set parameters for individual manual jobs at runtime, eliminating the need for costly full pipeline re-runs when requirements change mid-execution. Teams can now make real-time decisions based on earlier job outputs or changing external conditions—such as selecting deployment targets, adjusting configuration values, or specifying resource allocations—directly when triggering a manual job. Previously, when parameters were unknown at pipeline start or needed adjustment after reviewing earlier results, developers faced expensive workarounds: re-running entire pipelines with modified variables, manually editing CI configuration files, or using error-prone external scripts. This new capability is particularly valuable for enterprise teams with complex deployment workflows, where a single parameter change—like switching a deployment environment or adjusting a database migration flag—no longer requires restarting hours-long pipelines. By parameterizing individual jobs instead of entire pipelines, teams reduce compute costs, accelerate iteration cycles, and minimize deployment errors, while also addressing a critical workflow pattern for organizations consolidating from Jenkins to GitLab. </details>  This feature addresses critical customer escalations from high-value accounts more details in https://gitlab.com/gitlab-org/ci-cd/pipeline-authoring/-/issues/197 Legacy issue https://gitlab.com/gitlab-org/gitlab/-/issues/301061 ## Executive Summary Users cannot set inputs parameters for a single job within a ci/cd pipelines, forcing developers into a cumbersome and error-prone workflow that significantly impacts enterprise CI/CD operations. While its possible to set parameters for an entire manual pipeline, this functionality is missing for individual manual jobs. This gap in developer experience creates workflow disruptions, increases deployment errors, and forces expensive full pipeline re-runs for simple parameter changes. The problem is compounded by the fact that some input parameters are unknown or change dynamically during pipeline execution, requiring developers to make real-time decisions based on earlier job outputs or external conditions. In addition, it represents a primary competitive disadvantage preventing complete Jenkins consolidation. #### ARR impact On top of the escalation mention above, numerous high value customers (<100K ARR) requested this capability, see this confidential thread https://gitlab.com/groups/gitlab-org/-/epics/18551#note_2640549317 #### Engineering Assessment This will require us working with ~"group::runner". There has been [extensive coordination](https://gitlab.com/groups/gitlab-org/-/epics/17833#note_2609082134) in the process of refining this project between ~"group::pipeline authoring" and ~"group::runner" engineers already to ensure that no big surprises are to be expected here. #### Dependencies - Team dependencies: * ~"group::runner" * https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38952+s * https://gitlab.com/gitlab-org/gitlab-runner/-/issues/38953+s * ~"group::ci platform" * https://gitlab.com/gitlab-org/gitlab/-/issues/551830+s - Epic/Issue dependencies - https://gitlab.com/groups/gitlab-org/-/epics/17833 - Related issue https://gitlab.com/gitlab-org/gitlab/-/issues/301061 #### DRIs - **PM**: @dhershkovitch - **EM**: @manuelgrabowski - **UX/PDM**: @sunjungp - **Group(s)**: ~"group::pipeline authoring" - **Engineering Owner**: @cheryl.li #### Initiative Driver - Product or Engineering? - [x] **Product-driven initiatives (P1/P2/P3)** - **P2** - They may also receive GTM tier labels (T1/T2/T3) for external communication #### Sizing and Funding (Optional) - **Size**: L --- ### Hygiene Guidelines :bulb: _See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - [x] Update epic description with all relevant information - [x] Ensure all dependencies are identified - [x] Apply appropriate labels (see below) - [x] Apply target delivery Milestone - [x] Update interlock status as discussions progress (via label) ##### :two: Post-Interlock: once quarter begins - Update health status weekly (via label) - Document any newly identified risks or dependencies - Link to implementation epics/issues as work begins - Flag any scope or timeline changes immediately

epic