### Release notes Previously we made it possible to [surface pre-filled variables with values in the "Run pipeline" page](https://docs.gitlab.com/ee/ci/pipelines/index.html#prefill-variables-in-manual-pipelines), however changing the value is still a manual and error-prone process. In this release we've added the ability to set a list of predefined variable values for CI environment variables to make it easier to run a pipeline with the available variables, by surfacing a list of available values for environment variables we will reduce the complexity when you inject manual variables to a pipeline ## Competitive analysis * This is a similar feature to Jenkins [Active choice](https://gitlab.com/gitlab-org/gitlab/-/issues/29674) and [extensible choice parameter Jenkins Plugin](https://plugins.jenkins.io/extensible-choice-parameter/) plugin in Jenkins, some of our users requests this feature so they could rip out Jenkins, besides Jenkins * Azure DevOps has this feature implemented as radio boxes, but functionally the same as a dropdown menu:  The related yaml: ``` parameters: - name: oraProject displayName: Ora Project type: string default: Operations values: - Operations - Development - name: oraTaskId displayName: Ora Task ID type: string - name: deployMessage displayName: What is being deployed? type: string ``` ## Problem to solve In 13.7 we made it possible to [surface pre-filled variables with values in the "Run pipeline" page](https://docs.gitlab.com/ee/ci/pipelines/index.html#prefill-variables-in-manual-pipelines). Changing the value is still a manual and error-prone process. The CI users would like to be able to set a list of predefined variable values for CI environment variables to make it easier to run a pipeline with the available variables. The severity of this problem is well documented by multiple customers in the issue discussions below. ## Intended users - Sasha (Software Developer) ## Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> - Variable values array will be defined in YAML - The available variable values will be surfaced in the "Run pipeline" form as a list dropdown - The first value in the list will be the pre-selected value in the dropdown All other variable form behavior remains unchanged. #### YAML definition ```yaml variables: DEPLOY_ENVIRONMENT: value: staging options: - "staging" - "canary" - "production" description: "The deployment target. Change this variable to 'canary' or 'production' if needed." ``` #### UI dropdown The form should work exactly as it is working today, with the addition of a drop-down values menu for the pre-filled variables with multiple values. #### [View designs](https://gitlab.com/gitlab-org/gitlab/-/issues/29159/designs/design_1654068518841.png) #### Further iterations (out of scope, separate issues will be created) - Allow to add your own value even if there's predefined values - Allow for no default value - Allow to add variable values through the UI - Set value types and show different input depending on the value. https://gitlab.com/gitlab-org/gitlab/-/issues/351067 - Input validation for text input. ## Permissions and Security Existing variable permissions will be used. <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> ## Documentation Documentation required. <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ## Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ## What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> ## Implementation Table | Group | Issue Link | | ------ | ------ | | ~UX | :point_left: You are here | | ~backend | https://gitlab.com/gitlab-org/gitlab/-/issues/362934 | | ~frontend | https://gitlab.com/gitlab-org/gitlab/-/issues/363660 | ## Links / references <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->