Add CI variables modal and dropdown components

Context

This work is in a series of MR to create a new application in CI/CD settings for variable. Before diving in, there are a few important point on both the structure of the MRs and the code itself.

MR	Link
Add Modal and dropdown component	👈🏻 You are here
Add Table and Settings components	!94244 (merged)
Add Admin specific code	!94267 (merged)
Add group specific code	!94385 (merged)
Add project specific code	!94388 (merged)

MRs structure

The total refactor was around 3k diff, which was too big. Therefore, we are going to ship smaller pieces like some refactored components and their tests in sequence. These components are not used anywhere unless the feature flag ci_variable_settings_graphql is enabled. To make sure that each little piece of application that gets merged with passing specs, we start by the smallest possible component and we move up to the larger application components all the way to the root where we fetch the new Apollo data.

At any point, please feel free to consult: !91710 (closed) for additional code context. That MR has all the changes we are aiming to have merged with this series f MR

The work

Note that all older components that use vuex have been prefixed with legacy_.

The ci_variable_settings, which used to be the root of the variable settings application, is used in 3 different pages:

• Project Variables: /$user/$Project/-/settings/ci_cd
• Group Variables /groups/$my_group_name/-/settings/ci_cd
• Admin Variables /admin/application_settings/ci_cd

Here are some key details on some small differences between each of them regarding environment scopes (which means, in which environment is that variable available):

• Project variables always have a possible list of environment scopes
• Group variable can have a list of environment scopes if the feature flag group_scoped_ci_variables is turned on (which it is by default)
• Admin variables can never have an environment scope

At the end of this chain of MR, we are going to have 3 top level components (one for each section) to use the right queries and mutations based on which page we are on. It also allow children components to simply get props and emit events and can be agnostic to where their data is coming from.

As for feature specs, they will be enabled with each root component being added.

What does this MR do and why?

This part introduces 2 new components:

• The modal
• The dropdown list

The modal is used when adding or editing a variable, which means that we can get some props data to set if we are adding or editing a variable and if we are editing, the existing info on the variable. There are a bunch of fields, which when edited change the variable data property. When submitting, we emit an event with the variable data and the parent components will take care of making the mutations as needed.

The dropdown is a list of all the possible environment scopes.

Please note that it might look like a big diff (1000) but since there are about 400 lines of copy pasted specs, it's not that big. The other point to consider is that I believe that the modal and the dropdown should be reviewed together as they are part of the same UI, so this + the specs makes for a big MR that I think is the best compromise here.

Screenshots or screen recordings

None for now

How to set up and validate locally

For this step, nothing should be broken with the existing flow so it's not work checking if things work wit the feature flag enabled. The old flow should still work and although I don't think that at this step we should do all of this testing, if you disagree with me, then:

Make sure the feature is disabled either by never having enabled it, or doing in the rails console:

Feature.disable(:ci_variable_settings_graphql)

1. Visit each of the listed routes:

• Project Variables: /$user/$Project/-/settings/ci_cd
• Group Variables /groups/$my_group_name/-/settings/ci_cd
• Admin Variables /admin/application_settings/ci_cd

1. Make sure you can add a variable
2. Make sure can edit a variable
3. Make sure that you can delete a variable
4. Make sure you can create an environment scope in Projects and Groups. To do so, open the environment dropdown, type a search term that does not exist (E.g. my_new_env) and you'll see one of the dropdown item now gives you the option to add the search term as an environment
5. Make sure that any changes to variables is reflected in the table -->

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.