Bogus error alert when a team member adds a new GitLab project

[jankeromnes]

Bug description

When adding a new GitLab project as a team member, I'm immediately presented with an error alert:

However, adding the project was actually successful.

Steps to reproduce

In a regular browser window:

1. Log in with a GitHub account
2. Create a Team
3. Copy the Team Invite URL

Next, in a private browser window:

4. Log in with a GitLab account (this creates a new Gitpod user)
5. Visit the copied Team Invite URL (joins the previous team as a new member)
6. Try to add a GitLab project

You will see a pop-up that says Request createProject failed with message: UnauthorizedError (see above screenshot)

However, the project was actually successfully added to the team (you can see it if you navigate away from the error and back into the team projects)

Workspace affected

No response

Expected behavior

I shouldn't see the error alert, but instead be able to continue in the wizard as usual.

Example repository

No response

Anything else?

No response

[JanKoehnlein]

/schedule

[roboquat]

@JanKoehnlein: Issue scheduled in the meta team (WIP: 0)

In response to this:

/schedule

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[JanKoehnlein]

/assign

[JanKoehnlein]

When creating a project from a GitLab repo, we use the team owner's token to install the pre-build automation. In this case, this fails because the owner doesn't have a GItLab token yet, so we throw an error.

This raises a couple of questions

1. In the above scenario we currently throw an error in repositoryService.canInstallAutomatedPrebuilds. We could just return false instead thereby closing this issue. But in these cases we create the project without enabling prebuilds and without notifying the user about this.
2. Is it really OK to do something with the token of another user (the owner)? We should at least document such actions.
3. In this particular example, we're even switching to the wrong user, as the repo belongs to the plain team member. Shouldn't we rather switch to the repo's owner than to the team's owner?

My feeling is we shouldn't use another user's token and we should report back in the UI if prebuilds couldn't be enabled (with a link to instructions how to do this manually). But that'd require a protocol change. Opinions?

[jankeromnes]

When creating a project from a GitLab repo, we use the team owner's token to install the pre-build automation. In this case, this fails because the owner doesn't have a GItLab token yet, so we throw an error.

Wow. Excellent and scary find. Thanks!

@AlexTugarev For GitLab, do you remember why we impersonate a random owner from the Team to install the Prebuilds webhook, as opposed to doing it as the user who is adding the project? I think I remember a meeting where we agreed that impersonating other users is bad practice, and doing things as the logged-in user is:

• better (impersonation is bad)
• safer (we know the user currently adding a GitLab project has the correct access rights, e.g. a GitLab token)
• less surprising (if I'm the random team owner whose token is getting used here, and I audit what Gitpod is doing on my behalf, I could be very surprised)

Do you see any technical limitations that would prevent us from installing the Prebuilds webhook as the user who is adding the project, and not as a random team owner? (E.g. maybe I'm missing something regarding who has access to what, and using the logged-in user's token won't actually work.)