## Executive Summary GitLab would like to enable non-technical users to easily configure and trigger GitLab pipelines through an intuitive web interface with dynamic, cascading dropdown inputs. Current GitLab pipeline triggering lacks user-friendly input configuration, particularly for complex scenarios where input selections should dynamically influence available options in subsequent fields. **Competitive analysis** - This feature directly addresses competitive parity with Jenkins Active Choice, removing a key obstacle that prevents complete GitLab adoption and enables organizations to consolidate their CI/CD toolchain. **Business justification & ARR impact** see the full confidential thread- https://gitlab.com/groups/gitlab-org/-/epics/18546#note_2631332302 #### Engineering Assessment We won't have any external dependencies in the sense of building on other teams' work for this. The main concern would be ~frontend capacity – most ~"group::pipeline authoring" efforts are very ~backend heavy, but this one is at least equal parts frontend and backend. Frontend capacity is currently scarce in the group, so that would presently be the most "blocking" concern. Besides that we're in a good spot with having done a lot of prep / exploratory work on this topic. #### Dependencies - Team dependencies: - None - Epic/Issue dependencies: None #### 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)** - **P3** #### Sizing and Funding (Optional) - **Size**: L - **Funding Status**: - --- ### Hygiene Guidelines :bulb: _See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/ ##### :one: Pre-Interlock - Update epic description with all relevant information - Ensure all dependencies are identified - Apply appropriate labels (see below) - 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 <!-- Apply appropriate labels: - [ ] Section (section::dev, section::ops, section::sec) - [ ] Stage (devops::plan, devops::create, devops::verify, etc.) - [ ] Group (group::product planning, group::project management, etc.) - [ ] Interlock Priority (Product labels = Interlock Priority::P1, Interlock Priority::P2, Interlock Priority::P3, Engineering labels = Interlock Priority::E1, Interlock Priority::E2, Interlock Priority::E3) - [ ] Investment theme (Investment theme::Core-Devops, Investment theme::Security-Compliance, Investment theme::AI across SDLC) - [ ] Platforms (platform: GitLab.com, platform: dedicated, platform: dedicated for gov, platform: self-managed) - [ ] Subscription tier (GitLab Ultimate, GitLab Premium, GitLab Free) - [ ] Quarter (FY27 Q1, FY27 Q2, FY27 Q3, FY27 Q4) - [ ] Pre-interlock status label (interlock status::New/Proposal in progress, interlock status::cancelled, etc) - [ ] Post-interlock status label (R&D roadmap status::Executing, R&D roadmap status::Completed) - [ ] Post-interlock, once quarter begins update health weekly (health::on track, health::needs attention, health::at risk) *For guidance on labels, see the [labels guide here](https://gitlab.com/groups/gitlab-org/-/wikis/CXO-Operational-Dashboards/R&D-Interlock-Dashboard#labels-guide) -->