Skip to content

Frontend: Make it possible to set variables as non-expanded in CI/CD Settings > Variables

Release notes

Problem to solve

Currently majority of variables send by GitLab to Runner are subject to variable expansion and does not support special characters such as %. When users add a variable value with $ (which is very common for generated passwords), the value is treated as a variable reference, which isn't expected behavior.

Users find it surprising that the variable gets expanded by default when the value contains a $. Often times the value is machine generated and might contain a $ to make it more secure.

Note that UX here includes both within the web UI and .gitlab-ci.yml.

We should consider the following:

Intended users

UX definition of done

Click to expand

Problem Validation Phase

  • Problem is well understood and has been validated
  • JTBD is well understood and has been validated
  • [-] PM has communicated the opportunity canvas to stable counterparts and group stakeholders, including the Product Designer and Product Design Manager

Design Phase

  • Document the JTBD and UX goal in the issue/epic description
  • Explore multiple different approaches as a team
  • Discuss the technical implications with Engineering
    • Identify any potential cross-team dependencies and include the DRIs in the discussions
  • Identify a small set of options to validate
    • Document the user story(ies) for the MVC
    • Consider edge cases for each user story
    • Create prototypes or mockups for each user story
  • Pajamas component lifecyle
    • [-] Identify component design or pattern update/creation
    • [-] Discuss the technical implications with Engineering
    • [-] Pajamas issue is created (within the scope of the MVC)
  • Update issues/epic descriptions
  • Proposed solution(s) identified and documented in the issue/epic description

Solution Validation Phase

  • Validate the solution to increase confidence in the proposed solution
  • Document the solution validation learnings
  • Product Designer has communicated the solution validation learnings to stable counterparts and group stakeholders, including the Product Design Manager
  • Update the MVC proposal with relevant insights from the solution validation
    • Discuss the technical implications with Engineering
    • Update issue/epic description to contain or link to the findings 👈 We're here

User experience goal

When adding variables for my project I want to be able to add a password with a $ in it and for the variable to not be expanded.

User stories

  • When adding a variable in the CI/CD settings I want to easily create a variable value that will process as a raw string.
  • When adding a variable in the CI/CD settings, I want to easily see what are my options to configure the variable.
  • When adding a variable in the CI/CD settings with a $ in its value, I want to know that there's two options available to me to either process it as is, or create a variable expansion using the $ sign.
  • When looking at my variables list I want to see which variables are set to expand and which don't.

Proposal

Based on the feedback we've been getting in issues and during solution validation research, "raw" variable type should likely be the default processing for variables. However, this would require changing the current product behavior. In order to start with a safer, smaller iteration we will add an optional setting to the variables in CI/CD settings to turn off variable expansion.

The scope of this issue is to only address the UI aspect of adding new variables in the project and group CI/CD variables settings.

MVC Scope

  • Add help text to the Value input field as in this design.
  • Add an option "Expand variable reference" to the new variable form in the CI/CD variables settings. This setting will be turned on by default for all existing and new variables. User can turn it off manually when creating a new variable or editing an existing variable.
  • When user adds a value with $, update the alert text as in this design.
  • When user unselects "Expand variable reference", update the Value input help text as described in this design.
  • The variables table should show if the variable is expanded or not. See designs

Setting behavior:

  • Expand variable reference = Checked -> variable expands (the current and default behavior)
  • Expand variable reference = Unchecked -> variable value is evaluated as raw string

👉 View the designs

🔗 Figma file

Links / references

Permissions and Security

Documentation

This feature needs to be documented in the Project and Group CI/CD settings docs.

Availability & Testing

Implementation Table

Group Issues Issue Link Notes
frontend Frontend: Migrate CI/CD Settings > Variables from VueX to GraphQL #364375 (closed) Blocks MVC
backend Backend: Make it possible to set variables as non-expanded in CI/CD Settings > Variables #361934 (closed) MVC
backend Backend: Make it possible to set a raw variable in our syntax #353991 (closed) MVC
frontend Frontend: Make it possible to set variables as non-expanded in CI/CD Settings > Variables 👈 You are here MVC
backend Backend: Allow special characters to be used for raw variable types #352657 (closed) MVC
backend Backend: Make it possible to set variables as non-expanded in Project->pipelines/new #362539 TBD at a later date
backend Backend: Make it possible to set variables as non-expanded in Manual Job->Play #362548 TBD at a later date
backend Backend: Make it possible to set variables as non-expanded in Project->pipeline_schedules/new #362549 TBD at a later date

Available Tier

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

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.

Edited by Nadia Sotnikova