Show inherited group variables in project view

Problem to solve

When using a mix of project & group variables, it can be confusing to understand what group variables exist and how they may related/conflict with project level variables.

A simple iteration to help with this would be to show the group (inherited) variables in the project variables page.

Further details

Many enterprise customers will use group variables for stuff they have to set at a group level, but someone creating a new project in a group I may not be aware of what group variables exist.

Proposal

Show a read-only list of inherited variables (names, no values) and where they came from. The link should take you to where the value is defined so, if you have access, you can see and change the value.

The table includes columns:

• Key => Variable name
• Origin => Group name + link (not displayed in mockup)

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

As a user, I can identify what group CI variables exist when I'm in the project.

Links / references

added CI variables customer labels

/cc @jlenny

added devopsverify + 1 deleted label

/cc @tipyn

Thanks Brendan, this would be very helpful. One thought might be that the group variables might want to be read-only, and also indicate the group where they're getting sourced from.

For instance, if I've created MY_VARIABLE at my top Group and also in my Sub-Group, the variable would show its value in the Group Variables section in the project under Sub-Group and would indicate that the value from Sub-Group is being used, not the Group value (or vice versa). Having a link to navigate to the owning group would also be helpful.

I think keeping them read only might make sense too, making the user navigate to the group that owns the variables to make edits.

I agree they would be read-only I think.

added direction label

added [deprecated] Accepting merge requests label

@jlenny - is there a way we can get this out of the backlog and on the roadmap, please?

added 1 deleted label and removed 1 deleted label

It's a really nice idea, but I don't know where we could fit it in over other priorities. This would be a great gitlab-ce~2091545!

added Category:Continuous Integration label

Seems related to gitlab-ce#35841.

added grouppipeline execution label

@jhampton I spoke with a customer this week who has lots of nested subgroups which makes this a big pain point for them. Would be great if this could get prioritized

Thanks for the ping @ClemMakesApps!

@jlenny any concerns if we pull this into %12.5 for @pburdette to work on?

changed milestone to %12.5

assigned to @pburdette

removed [deprecated] Accepting merge requests label

changed milestone to %12.5

added UI polish label

changed the description

@dimitrieh this could probably use a UX check. The comments above that the source should be shown is relevant, along with a link there. I'm also not sure showing a hidden value with no unhide button is adding anything important for example.

@jlenny a possibility would be to show it in a collapsed section initially so you are able to check this within context.

@dimitrieh we should make a UX decision here so planning can complete.

I changed the description to what makes sense to me, but please double check.

@jlenny @pburdette @jhampton Preferably I'd base the solution of this issue on the to-be-implemented design of #27480 (closed).

This would mean that another simple table can be positioned below which displays these variables including a small explanation text like this:

This mockup still misses origin information and links

This is not blocked by #27480 (closed) but will give an incoherent display of variables if #27480 (closed) has not yet been implemented.

Would love your thoughts!

@dimitrieh let me know if I'm understanding this correctly.

A user has created a group named GOT and has defined several CI variables.

Within the GOT group there are subprojects, such as snow.

Within the snow project there will be a section under settings that will show all variables defined within GOT.

@pburdette that is correct, in the project settings there is currently already a section for project variables. This adds another table displaying the variables it inherits from its parent groups.

@dimitrieh should each key be a link itself back to the group project settings ?

@dimitrieh I have the functionality there. Of course this doesn't have the styling that's going to be implemented in #27480 (closed). It uses the previous styling there.

Should each key be a link? Maybe not?

The link that goes to the groups settings page for ci_cd ? Should we expand the section on load?

group_vars

@pburdette the mockup currently does not show a second column for the table Origin. This column should display the group name and act as an anchor.

I edited the description of this issue to include this!

Will you update the styling of the new table to be similar to the mockup? If possible the origin column should be left-aligned taking up 50% width.

How does this look? @dimitrieh

@pburdette Looking great! 3 questions:

• Is this making use of the table component styling? The headers seem a little too low on contrast.
• Where does the origin blue icon link towards? If this links to the group, I'd argue that variables can be inherited from multiple groups due to hierarchy. Meaning that in the example, I'd expect dbz to be the name of the group and the anchor.
• Can we allow for more width for the key values?

Is this making use of the table component styling? The headers seem a little too low on contrast.

Table component as in gitlab-ui? No this code is still in Haml, no Vue. I wasn't sure of the hex value from your mock. So I went with the light-grey class we have which is #bbb

Where does the origin blue icon link towards?

If this links to the group, I'd argue that variables can be inherited from multiple groups due to hierarchy. Meaning that in the example, I'd expect dbz to be the name of the group and the anchor. Yes links to the group. We for sure can make the origin name the actual link. Interesting, do you have a use case you could share with me regarding project variables that are inherited from multiple groups? I was under the impression that a project could only belong to one group.

Can we allow for more width for the key values?

Yes! Do you mind giving a mockup so I can get this down pat?

@pburdette

Table component as in gitlab-ui? No this code is still in Haml, no Vue. I wasn't sure of the hex value from your mock. So I went with the light-grey class we have which is #bbb

Got it, can you make it so it has the same styling as the vue component?

Yes links to the group. We for sure can make the origin name the actual link. Interesting, do you have a use case you could share with me regarding project variables that are inherited from multiple groups? I was under the impression that a project could only belong to one group.

https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com is within a subgroup of a group. Meaning that it can inherit variables both from the main group as well as the subgroup:

@matteeyah can you confirm this is correct?

Yes! Do you mind giving a mockup so I can get this down pat?

Oh I think that is correct :)

@dimitrieh okay I made some changes, hows this look?

looking good! Left a last comment about design in the merge request!

added 1 deleted label

added 1 deleted label

changed the description

added UX label

added frontend label

added workflowdesign label and removed 1 deleted label

assigned to @dimitrieh

added Deliverable label

@matteeyah Do we need to update ci_cd_controller.rb to handle group level defined variables?

What do you mean by 'handle'? If I'm reading this correctly, this issue is just about showing existing group variables in the project variables settings view?

Yeah that's correct. Just didn't know if on backend if we needed to update this controller. It looks like it is handling everything for project specific views regarding ci/cd settings variables. Just thinking in terms of smartest way to get group level variable data into the setting view.

If it's in HAML this should do the trick - project.namespace.variables

removed 1 deleted label

removed 1 deleted label

changed the description

added workflowin dev label and removed workflowdesign label

mentioned in issue #27480 (closed)

mentioned in merge request !18759 (merged)

@pburdette per our chat, adjusting this issue to ~"workflow::In review"

added workflowin review label and removed workflowin dev label

mentioned in merge request gitlab-com/www-gitlab-com!33031 (merged)

@jhampton @pburdette it looks like this one has been in review for a week now, is that normal or a sign things are getting stalled out?

@jlenny I'd say normal. I'm going to pass it to a maintainer soon. Had to go through three reviewers before I could pass it to a maintainer. Should be merged soon.

@jlenny just passed to maintainer

mentioned in issue #35400 (closed)

closed via merge request !18759 (merged)

mentioned in commit 8725f0ed

mentioned in issue #207907

mentioned in issue #225195

mentioned in issue #246534 (closed)

To further this awesome feature, I have added #246534 (closed).

cc @brendan @jrreid

cc internal https://t-mo.slack.com/archives/CKYFLNMD3/p1599326393079200

mentioned in issue gitlab-com/www-gitlab-com#9140 (closed)

mentioned in issue #428174 (closed)