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
UX DoD
⭐ ️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
in addition to defined process)
Criteria for Engineering DOD (-
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*`.
- If so, the UI should inform what the user is creating. The call to action option in the dropdown should read as
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