Clarify the grouped CI variables environment scope experience
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
There is currently a feature flag for group variables called groupScopedCiVariables which allow groups to have "scoped variables", which we can think of as variable which only exist within a scope. In practice, it behaves kind of like what we would expect for setting an environment on a project variable. However, there are a lot of questions around this feature and this issue should aim at clarifying and rectifying any problem of UX around this feature.
Why is this still behind a feature flag?
This is a pretty old feature flag and I am not sure if we are leaving it there so that users can enable or disable it depending on their need, but if that's the case then it should become a group setting, not a feature flag. Therefore, either we need to make this new setting OR we can clean up the flag and have scoped variables be a thing.
What are the permissions for scope variables?
While working on #298814 (closed) I realized that even if we added some conditionals around fetching environments, it would not work the same way on scoped variables because we get the environments from the variables read_environment settings is turned off?
Are scope variables the same as project variables with environments?
Reading the code, intention is not clear here. We are fetching the "group environments" by fetching all the variables and making a list of all of their environments. We also allow a user to create a new environment when assigning one to a group variable, so these "scopes" are not fetched from the API, but inferred bu the current list of variables. If they were real environments, then we should be able to fetch them through graphQL the same way we do for projects.
That would mean that a "scope" for group means that let's say I have dev as the scope for this group. That would mean that this variable is available in any project under that group that has that scope. It would also mean that permissions behave the same: if you don't have permission to read_environments then this applies to project and group environments.
If it's different and scopes serve a different purpose, then how do they behave? And why are we getting them through the variables? There should be a data point access where the client can ask for an exhaustive lists of these group scopes. We would also need to determine how the behave (when are they applied) and in what way do they differ? And if they do differ, we should communicate this in the UI.