Docs - product feedback: Group level environment variable scoping with wildcard

Proposal

I've been trying to figure out what were all the level of environment scoping that could be applied to a group for inheriting on the different project we serve. As we're starting from a legacy deployment structure and migrating to a new way where we can assign a new level of granularity (using Gitlab's environments in our case), we're trying to group some of those variable to environment that match a pattern (production/* and production/site* ). But while trying to figure out how that would work with subgroups, project and groups, I've kind of hit a non-deterministic behaviour where sometime, the first one was taken while the other time, the second was taken. It does seems to follow something behind, but as soon as I modify the list, it could change between both (even if I deleted a variable that was not related to production ! If there could be some consistency, then I wouldn't have minded, but it seems a video was made explaining that it should be supported, while the example in the pipeline seems to have been broken for a while ;

https://www.youtube.com/watch?v=v4ZOJ96hAck&ab_channel=GitLabUnfiltered

Is this one of the youtube account that gitlab support?

Anyway, any insights into the mechanic would be appreciated as I didn't find anything related to group environment scoping with wildcard.

FYI, I did test the project > subgroup > groups, that seems to work flawlessly as long as it match one of the environment at any of those level, which is what I would expect. It's just I would expect the wildcard rule to be respected at every level as well.

Edited by Eric Lafontaine