Dynamically pre-filled global variables when running manual CI/CD pipelines
<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Update Moving the discussion to https://gitlab.com/gitlab-org/gitlab/-/issues/520094 ### Problem: Since v13.7 gitlab allows global variables to be pre-defined and pre-filled in gitlab-ci.yml on root level. This allows developers to choose a pre-defined value for a variable from a dropdown list. This is useful for static values, but not the best experience when values need to be generated dynamically from an external source, all the more when logic needs to be applied to extract those values (breaking down and filtering some complex json object to generate an array of options etc...) ### Additional details (probably separated issue) * In some use cases, user would like to choose multiple values for a single variable (checkbox) * Also, options for variable **B** could depend on value chosen for variable **A** Solution: Allow generating options with **script** keyword, using inline bash script, or script from a file Allow multiple selection (checkbox) Allow referenced variables (variable **B** is rendered based on variable **A**) ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/product/personas/ * [Parker (Product Manager)](https://about.gitlab.com/handbook/product/personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/product/personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/product/personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/product/personas/#rachel-release-manager) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/product/personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/product/personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/product/personas/#eddie-content-editor) * [Amy (Application Security Engineer)](https://about.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Isaac (Infrastructure Engineer)](https://about.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/product/personas/#cameron-compliance-manager) --> DevOps engineers - as pipeline developer Softwear engineers - as edge user ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/product/ux/ux-research-training/user-story-mapping/ --> Allow developers to run manual pipelines with dynamically generated list of variables and their respective values ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> ```yaml variables: include: # Multiple sources are allowed (should be merged into a single property) - # path to variables.yml in source code - # relative path to another project in gitlab - # url to external source - name: # String (variable name) displayName: # Optional - String (Readonly, variable name displayed in UI, defaults to name) type: # String | Checkbox | Dropdown defaultValue: # Optional - String (defaults to options[0]) | Array of strings (when type is Checkbox) options: # String | Array of strings - script: # bash script | script from file (must return string or array of strings) description: # String references: # other pre-defined variable which value is used to generate the options for this variable filter | searchbox: # Boolean (whether to display searchbox or not) ``` Example for includes: ./variables/var1.yml ```yaml name: VAR_1 type: Dropdown options: - script: '/bin/bash ./var1.sh' description: "please select a value" references: 'VAR_2' searchbox: true ``` ./variables/var2.yml ```yaml name: VAR_2 type: Checkbox options: - script: '/bin/bash ./var2.sh' description: "please select values" searchbox: true ``` .gitlab-ci.yml ```yaml variables: include: - './variables/var1.yml' - './variables/var2.yml' ``` should result with: ```yaml variables: - name: VAR_1 type: Dropdown options: - script: '/bin/bash ./var1.sh' description: "please select a value" references: 'VAR_2' searchbox: true - name: VAR_2 type: Checkbox options: - script: '/bin/bash ./var2.sh' description: "please select values" searchbox: true ``` ### Links / references - https://javadoc.jenkins.io/plugin/uno-choice/org/biouno/unochoice/CascadeChoiceParameter.html - https://plugins.jenkins.io/uno-choice/ <!-- Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->
epic