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

This caused confusion here too: https://gitlab.com/gitlab-com/support-forum/issues/3069

@dimitrieh it seems that we could improve the environment input field, since this is not probably so clear to users. See also https://gitlab.com/gitlab-com/support-forum/issues/3069 and https://gitlab.com/gitlab-org/gitlab-ce/issues/44450 for other similar reports.

Maybe we can do this:

1. fetch existing environments for the project
2. fetch environments names set for other secret variables
3. populate the list with entries from 1 and 2
4. allow also arbitrary entries, so users can add environments that don't exist yet

What do you think about this flow? If the user selects one of the existing entries, the input field will be prefilled with the value. If the direct input doesn't match any, it will saved as-is, without any further action to do.

It is a little different from other places where we are using the same control, but probably it is worth to be addressed so we can use it in other places, like environment selection when adding a Kubernetes cluster.

changed milestone to %10.8

added Deliverable label

added featureenhancement label

added backend frontend labels

assigned to @cperessini

@bikebilly I will let @cperessini take a fresh look on this problem as he is assigned to this issue

Giving the user smart options sounds like a good idea to me in any case

@bikebilly I think this proposal is pretty similar to what you described in https://gitlab.com/gitlab-org/gitlab-ee/issues/5313#note_64300812 I looked at different approaches and this is the one that makes the most sense to me:

Add a table header to the variable list, with column titles: Variable key, Variable value, Protected and Environment scope. This is to gain some horizontal space by removing the Protected label from each row as well as better organization.

Replace the Environment dropdown button with a plain text input. When creating a new variable, this input will be empty by default. If the user saves without specifying this field, a * will be added.

When the user clicks on the input field, an autocomplete dropdown appears. It would work similarly to the issue/MR search.

The options in this dropdown will be:

• * (All environments)
• Project environments
• Environment names used in other variables

All these values are shown without distinction because I think separating them in different sections would indicate to users that they can only select one of the values in the list, and would deter them from trying to type in their own string.

When the user starts typing, any environments that match the string will be highlighted in bold.

A new row appears at the bottom containing the exact string the user typed in double quotes. This way, we indicate that they can use that as a custom value.

This dropdown should be navigatable with the arrow keys and selectable with the Enter key (same as issue/MR search)

If the user selects their custom option, it gets displayed in plain text form and it will be possible to select it from the dropdown when a new variable is added in the future.

@dimitrieh Could you help me out with this issue while I am away next week? If the proposal is accepted, the description needs to be updated with the contents of my last comment. Thanks a lot!

assigned to @dimitrieh

mentioned in commit gitlab-design@0351d980

What do you think of @cperessini proposal here https://gitlab.com/gitlab-org/gitlab-ee/issues/5313#note_68381109 @bikebilly? Chris is away this week but others on the team can assist to get this over the finish line.

assigned to @lbennett

Great concept @cperessini I have moved it to the description

Replace the Environment dropdown button with a plain text input. When creating a new variable, this input will be empty by default. If the user saves without specifying this field, a * will be added.

I wonder how this is going to feel. Let's check this out in the ux review of the merge request. I wonder if just having the default value be * (All environments) where (all environment) is not part of the real value so to say is a more transparent option

I wonder if we can make it additionally clear that wildcards are supported also in the form of prod* etc. This should at least be documented cc: @axil

@lbennett (this should be quite ready to go)

changed the description

added ~2024186 and removed UX labels

unassigned @dimitrieh

@lbennett what is the status of this MR?

@ayufan This won't make it into next release

changed milestone to %11.0

added missed-deliverable label

OK. I moved that to %11.0.

I wonder if we can make it additionally clear that wildcards are supported also in the form of prod* etc. This should at least be documented

@dimitrieh we have docs for this in https://docs.gitlab.com/ee/ci/variables/README.html#limiting-environment-scopes-of-secret-variables!

thanks @axil

cc: @cperessini :D

mentioned in merge request !5578 (merged)

I have another question for wildcards. The UI says: Create wildcard production, so is the asterisk (production*) implied or not? I need to create a variable that will apply to all environments starting with review/. Do I enter review/ or review/* in the environment scope field?

In the Kubernetes integration, the environment scope requires the asterisk (I think) if the environment is dynamic https://docs.gitlab.com/ee/user/project/clusters/index.html#setting-the-environment-scope.

For the protected branches/tags we require the asterisk as well https://docs.gitlab.com/ee/user/project/protected_branches.html#wildcard-protected-branches.

assigned to @okoghenun and unassigned @lbennett

@okoghenun Can you please take a look at this for 11.0?

@axil from the docs you listed in https://gitlab.com/gitlab-org/gitlab-ee/issues/5313#note_71432513 I can see the asterisk is required for it to be considered a wildcard:

Wildcards (*) can be used along with the environment name, therefore if the environment scope is review/* then any jobs with environment names starting with review/ would have that particular variable.

I'm adding a help line text to the dropdown so we can link to those docs:

changed the description

mentioned in commit gitlab-design@0c23be18

added workflowin dev label

mentioned in merge request !5915 (closed)

@cperessini Can you please share designs for mobile as we discussed.

changed the description

@okoghenun Just updated the description. There's a guideline that mobile dropdowns should be full-width. I know that settings pages have a weird margin situation on the right side, so it's okay if the dropdown needs to be limited inside this margin.

Noted @cperessini. Thanks for the updated UI's

@bikebilly @cperessini I'd like to confirm if these new design will also apply to CE because the delete button on mobile will look out of place as there is no option to provide 'Environment Scope' in CE.

mentioned in issue #5893 (closed)

@okoghenun this will not go in CE. This is what CE looks like right now (with a - icon instead of the proper trash icon)

I agree that the placement of the icon is less than ideal, but it works for now, so let's keep moving with this issue. We can create a separate issue to move the icon to a better place on mobile

mentioned in commit gitlab-design@88e0f531

mentioned in merge request !5974 (closed)

changed milestone to %11.1

added Stretch and removed Deliverable labels

I'm waiting for clarification from @timzallmann, for now this got %11.1, and Stretch.

mentioned in issue #5488 (closed)

added workflowin review and removed workflowin dev labels

changed milestone to %Backlog

added devopsrelease [DEPRECATED] label

mentioned in issue #7264

Adding ~"Accepting Merge Requests" to ~"UX ready" item.

added [deprecated] Accepting merge requests label

added 1 deleted label and removed 1 deleted label

removed [deprecated] Accepting merge requests label

added Community challenge label

marked this issue as related to #9441 (closed)

We should use the same component with Feature Flag's environment scope dropdown https://gitlab.com/gitlab-org/gitlab-ee/issues/9439. It works nicely and can search environments correctly.

Related: https://gitlab.com/gitlab-org/gitlab-ee/issues/9441

removed missed-deliverable label

mentioned in issue #11762 (closed)

added Category:Release Orchestration label

unassigned @okoghenun

added 1 deleted label

added Enterprise Edition label

Hi, I was about to open a ticket when I saw this one, it's quite old so not sure where do you guys stand about it

Today, it actually looks like this:

Which is very wrong in my opinion as it will not create a "wildcard" matching for test. A wildcard would be test*.

I suggest that when typing test (if it does not exist), the UI says:

Create new entry test (call to action)

This will exactly match the environment named test (help text, smaller font size)

If I'm typing test* then the UI will say:

Create new wildcard entry test* (call to action)

This will match all environments starting with test (help text, smaller font size)

Happy to discuss this further!

Added environments label

Leaving in backlog, waiting for further demand

added environments label

@darbyfrey @jhampton This issue is marked with ~"workflow::In review" - is this already coded or was this mislabeled?

This seems to be mislabeled, moving to workflowready for development

Thanks @darbyfrey!

@darbyfrey @ogolowinski calling out the MR for this issue that was created a while back. Please let us know if frontend should prioritize the review in upcoming milestones. !5974 (closed)

@jhampton is there value in delivering this MR on its own?

As we get closer to %12.8 we can set aside some time for the frontend DRI to start reviewing !5974 (closed). It has not been a high priority up to this point.

added workflowready for development label and removed workflowin review label

Setting /milestone to %12.8 as this issue is ready fro development, I do not want to postpone it

changed milestone to %12.8

added cicdplanning needs weight labels

removed needs weight label

@jhampton - can you see if this issue is worth breaking down?

Thanks Jackie. I think we will need to dedicate time in %12.8 to review the existing MR !5974 (closed). It has been sitting for a while and is a bit large.

@jakeburden lets please touch base about this issue when you are back .

haha. Just saw this comment in the MR !5974 (comment 263195894)

assigned to @jakeburden

changed milestone to %12.10

changed milestone to %13.0

added cicdactive label and removed cicdplanning label

added GitLab Premium label

added to epic &2439 (closed)

removed 1 deleted label

added UX label

mentioned in epic &2439 (closed)

unassigned @cperessini

assigned to @rayana

mentioned in merge request !27699 (merged)

@jmeshell here's some considerations about this issue:

• The scope/UI in the SSOT is outdated and does not reflect the latest changes made to the environments variables section. The interaction was refactored in #27480 (closed) and by the end of %12.10 a complete new UI will replace the current one !27699 (merged). This deprectates the design section in this issue #5313 (closed)
  • see UX issue by devopsverify #27480 (closed)
  • see MR !26098 (merged)
  • see walktrhough video of new UI https://www.youtube.com/watch?v=GT2ViXuAQ1Q&feature=youtu.be
• The first criteria in the design section is already fixed by the issues linked above/
  • Done by devopsverify: _Add a table header to the variable list, with column titles: Variable key, Variable value, Protected and Environment scope.
• The remaining acceptance criteria in the design section are also outdate, and don't comply with our current design/Pajamas guidelines.
• I will also need to check with someone to make !27699 (merged) available behind a feature flag, since I need to test and validate the interaction that was refactored there before I can prototype/scope this issue.
  • @jakeburden perhaps you can help me here? I need to see the MR above locally. Screen sharing would also help me :)

I'll go ahead and update the contents of this issue (SSOT) and point to the items that are still pending/open UX investigation.

I'll also apply the UX DoD to it https://gitlab.com/gitlab-org/ci-cd/release-management-group/release-management/-/issues/21.

@jmeshell I updated the issue description. Can you please check and complete the sections about the buyer and tier?

@jakeburden can you also have a look and let me know how this looks like from a frontend perspective? I'll ping you for a chat this week so we can align it faster thanks!

Moved it back to workflowdesign

@jakeburden I need help with those questions:

• Is the asterisk * character required to create wildcards? #5313 (closed) (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*`.

@rayana - I moved this out of cicdactive since this is not ready for development and also we should consider if it should be delivered in %13.0 so I moved it out.

@jmeshell I learned from @dimitrieh that the changes tackled by devopsverify are going to be reintroduced in %12.10.

@rayana - as in the problems of this issue will be reintroduced?

@jmeshell no, as in the problems I identified will be fixed by devopsverify . They already fixed/merged it, and reintroduced the UI pattern I mentioned here:

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.

That means we should be able to build on top of their code/UI, hopefully with no problems.

But I still need help to understand some of the problems I raised here #5313 (comment 318439571)

Oh perfect thank you for explaining - I will wait for Jake to get back and answer those. thanks @rayana

Looking back at this, and to answer those questions @rayana and @jmeshell:

• Is the asterisk * character required to create wildcards?

Using an * is not required when creating a wildcard environment scope, but it doesn't really function as a wildcard environment scope without one. You can create a wildcard EnvironmentName scope, but that doesn't contain the same qualities that EnvironmentName/* would have, in which the variable would be scoped to any environment that starts with EnvironmentName/ in the latter version.

From our docs:

Wildcards can be used, and the default environment scope is *, which means any jobs will have this variable, not matter if an environment is defined or not.

For example, if the environment scope is production, then only the jobs having the environment production defined would have this specific variable. Wildcards () can be used along with the environment name, therefore if the environment scope is review/ then any jobs with environment names starting with review/ would have that particular variable.

• 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*`.

Only variables (and file variables), and wildcard environment scopes can be created in this UI. It might add some clarity to add a tooltip or link defining what a wildcard environment scope is in this UI.

Should note that there has been significant updates the the Variables UI since this issue was opened. The UI now looks like this:

@jakeburden @rayana

It might add some clarity to add a tooltip or link defining what a wildcard environment scope is in this UI.

I agree with this... should this be a separate issue?

@jmeshell @rayana yes, I think since the original problem to solve from this issue is resolved now:

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.

So I'll make a separate issue to clarify what creating a wildcard scope does in the UI, and I think we can close this issue?

Yeah that works @jakeburden

Issue created: #231529 (closed)

changed title from Creating an environment wildcard is weird to Improve how to select an environment variable

changed the description

added workflowdesign label and removed workflowready for development + 1 deleted label

changed title from Improve how to select an environment variable to Improve how to select an environment variable wildcard