<!-- 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 --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ## :point_up: Problem When running a manual job from the manual job page, it's possible to [add custom variables for that job](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/24935). Right now it's not possible to view or override the variables being used when retrying the job. Developers want to be able to tweak variables used by a manual job when working on a deployment, for example. Sometimes you need to go back and tweak the input. ### Intended users * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Metrics <!-- How are you going to track uage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> - Click rate on the Variables tab - Number of users retrying manual jobs with updated variables vs. retrying with the existing variables ### User experience goal The user should be able to view the custom variables used by a manual job, update them if necessary, and retry the manual with with updated variables. <!-- 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/engineering/ux/ux-research-training/user-story-mapping/ --> ## :bulb: MVC Proposal - For manual jobs, add offer two "Retry" action types: "retry" and "update variables". - The "retry" action remains unchanged, it retries the job with the same variables. - The "update variables" action opens the manual job page with the variables form where the used variables can be viewed and updated. :point_right: For the detailed description of the user flows [see the designs.](https://gitlab.com/gitlab-org/gitlab/-/issues/32712/designs/Manual_job.png) :triangular_ruler: [**SPECS IN FIGMA**](https://www.figma.com/file/8WqthzcG69lRQtG5Lusfdb/%F0%9F%92%9C-CI%2FCD-Variables?node-id=2095%3A12228) :frame_photo: [**DESIGNS**](https://gitlab.com/gitlab-org/gitlab/-/issues/32712/designs/Manual_job.png) #### Permissions and Security User can only view the variable and value in the manual job if they have the permissions to view those variables based on their role in the project. ### Documentation This feature needs to be documented in the Variables and manual jobs documentation. <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? 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? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### Available Tier * Free ### Further iterations * Surface all available variables for that job (not only custom variables) * Add the variables form to all jobs (not only manual jobs) * Improve the form input to [include filtered search to make it easy to select available variables](https://gitlab.com/gitlab-org/gitlab/-/issues/344826) * Surface the project level variables that are being inherited by the job, and indicate when they're being overridden by the custom variables. Those can be view-only since they're set on project level, but it can be useful to see them for the context. * There can be further improvements to the variables form, for example when a variables has "true" or "false" values we can automatically offer those options in the dropdown. * Offer possible variable values to choose from a given variable ## Implementation Table | Group | Issue Link | | ------ | ------ | | ~UX Design | **:point_left: You are here** | | ~backend | https://gitlab.com/gitlab-org/gitlab/-/issues/361236 | | ~frontend | https://gitlab.com/gitlab-org/gitlab/-/issues/361237 |