Skip to content

Improve how to select an environment variable wildcard

Problem to solve

As a user, when I'm managing environment variables with GitLab, I want to be able to see, search, or create a scoped environment in the UI, so that I can quickly define the correct environment for my variable.

Intended users

Devon (DevOps Engineer)


UX DoD

Do not remove this expandable section. The content below is part of the UX Definition Of Done process. DRIs: @rayana @jmeshell

️SEE UX DEFINITION OF DONE

Entry Criteria for Design

  • Problem has been validated
  • Has UX effort accounted for in long term cycle, we know unknowns

Criteria for UX DoD

  • UX label is added to the issue
  • User stories and acceptance criteria have been created
    • Edge cases were considered
  • Cross-team dependencies have been identified, if applicable
  • Prototype or mock for each user story have been created
    • Empty states
    • Responsiveness
  • If changes involve copy, UI text label has been added
  • Pajamas: UI Component design have been identified
    • Pajamas issue is created (new workflow)
  • Marked as Ready for engineering evaluation per user story moved into workflowplanning breakdown & needs weight

Entry Criteria for Ready for Development

  • Scope has been defined and reviewed with engineering
  • User stories have been weighed and are less than 5 MRs
  • Create new issues for follow up user stories

Criteria for Engineering DOD (in addition to defined process)

  • UX review for MRs that include user experience changes - mandatory for frontend that has impact to UI/UX
  • Update SSOT in issues:
    • Update prototypes of deliverables
    • Add link to documentation
  • Create new issues for follow up and open scope

Further details

Today, when creating environment-specific variables, if the user types in something like production for the environment scope, the box returns the options No matching results and Create wildcard production.

Showing No matching results kind of makes sense given that a production environment doesn't exist yet. User can proceed by clicking the Create wildcard production. One of the questions raised originally was: What does creating a wildcard even mean? Especially since this isn't a wildcard at all. A wildcard would be production*.

In this case, the user should not be creating a new production wildcard, but production*. The asterisk is implied, and that causes friction when interacting with the UI.

If the user has an existing environment called production, the option is displayed in the UI, and the user can select it and proceed. Existing environments are displayed in the searchable dropdown option.

A recent change !27699 (merged) removed this pattern from the UI. We need to investigate how to reintroduce the searchable dropdown, and why the interaction is no longer available.

Questions that need investigation

  • Is the asterisk * character required to create wildcards? #5313 (comment 71893637)
  • Can users create anything other than an environment wildcard from this UI?
    • If so, the UI should inform what the user is creating. The call to action option in the dropdown should read as Create new wildcard production*`.

Proposal

TBA

Permissions and Security

The environment wildcard is set up at the project and group levels. It requires a project owner to configure.

Documentation

Yes, documentation update is necessary.

Availability & Testing

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

What is the type of buyer?

Is this a cross-stage feature?

Yes, devopsverify. CC @dimitrieh @jj-ramirez @thaoyeager

Links / references

Edited by Jake Burden