Environment scope doesn't apply consistently for GitLab subgroups

[peat-psuwit]

Bug description

When open a GitLab repository which resides in a subgroup, the environment variable scope which specify the top level group only doesn't apply consistently between the resulting env applied and the result of gp env.

Steps to reproduce

1. Go to https://gitpod.io/variables, set a variable e.g. VISUAL=gitpod-code --wait, and set the scope to ubports/*.
2. Open a workspace for https://gitlab.com/ubports/core/packaging/libayatana-common (Shortcut: https://gitpod.io/#https://gitlab.com/ubports/core/packaging/libayatana-common)
3. Using terminal, compare echo $VISUAL with gp env. echo $VISUAL would show the GitPod's default (/ide/bin/remote-cli/gitpod-code), while gp env would show the set value (gitpod-code --wait).

Workspace affected

No response

Expected behavior

echo $VISUAL should produces the same value as gp env would display. Preferably for my usecase, my variable set should apply to actual environment variables.

Example repository

https://gitlab.com/ubports/core/packaging/libayatana-common, or any repositories under https://gitlab.com/ubports/core/packaging really.

Anything else?

No response

Front conversations

[axonasif]

#2702 seems related.
cc @JanKoehnlein

As an temporary workaround, you could do put eval $(gp env -e) on your ~/.bashrc from a custom dockerfile.

[geropl]

@jldec I created a group "Environment Variables" for this. I'm not sure how our plans for deprecation of "user scope env vars" looks like.

But I guess:

• it's blocked until we have secrets
• then we need a smart integration of gp env with project-level env vars...?

OR: are user level env vars meant to stay? 🤔

[J0F3]

I have exactly the same problem. Variables are visible through gp env but not set as an environment variable. Only when I set the scope to */* the variables get set automatically. But that is definitely not what I want to do.

@geropl What do you mean by group? A team or a GitLab Group?

[raphaeltm]

Just want to add that I've been running into this issue as well.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[peat-psuwit]

Ping. Are you still taking a look into this?

[ceefour]

I want to echo @J0F3 's issue that is happening to me too:

I have exactly the same problem. Variables are visible through gp env but not set as an environment variable. Only when I set the scope to */* the variables get set automatically. But that is definitely not what I want to do.

[ceefour]

@J0F3 @axonasif I have updated info on Gitpod's behavior as of 26 Dec 2022:

Project path (GitLab repository): soluvas/appstudio/appstudio-auditor

Test results:

Pattern	gp env	Shell env
soluvas/appstudio/appstudio-auditor	Set	BUGGY! Not set
soluvas/*	Set	BUGGY! Not set
*/appstudio-auditor	Set	Set
*/*	Set	Set

@J0F3 so a "less worse than */*" workaround is using fixed project's name in the pattern, while the group becomes the wildcard ;-)

[axonasif]

Thanks for sharing your findings.

[kenibrewer]

I have also encountered this bug, it definitely was a a big headache to figure out the problem when I was working to onboard my colleagues onto GitPod.

This is particularly important Re: secrets that I want to be especially protective of. I'd really like to limit secrets to as narrow-of-a-scope as possible and needing to set them to / feels very insecure.

[axonasif]

👋 @kenibrewer could you please react with a " 👍 " on the top (message) of this issue?

[J0F3]

@ceefour Thanks for the Info. Looks a little bit better.

What I have done finally as a workaround was to add the following line to .gitpod.Dockerfile:
RUN echo "eval \$(gp env -e)" >> ~/.bashrc.d/400-gp-env

As I am using a custom image anyway this works for me...

[axonasif]

Nice workaround @J0F3! You could also utilize the dotfiles feature with a install.sh that would execute the commands each time you open any workspace. Your install.sh could contain:

#!/usr/bin/env bash

printf 'eval "$(%s)"\n' "gp env -e" > ~/.bashrc.d/400-gp-env

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kenibrewer]

This issue was resolved in #17831 and can be closed.

In case anyone is having issues with gitlab subgroup scoping, be sure to use the pattern org/** instead of org/* to match org/subgroup/repo.