New Project flow fails detection on private repos if oauth is fresh

[jldec]

Bug description

A totally new user will not be asked for repo scope when they log in the first time but they may grant access to a private repo to the Gitpod app during the new project onboarding flow. This results in the following errors

Steps to reproduce

• sign up as a new user
• create a new project
• provide access to a private repo when installing the Gitpod app in your GitHub account.
• select that repo after choosing the team
• detection spins - and console shows errors

Expected behavior

No response

Example repository

No response

Anything else?

No response

[svenefftinge]

I think this is high priority, as we already point everyone to creating a new project when they first land in gitpod (because 'project'S has become the default page) and we suggest users import their projects it is likely that they import a private one and get blocked by this.

[jldec]

Actually we have not merged this new flow as the default yet - #6048 (comment)

[jldec]

/schedule

[roboquat]

@jldec: 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.

[AlexTugarev]

Just to clarify, what's the expected behavior here?

Obviously we can detect the NotFoundError on the configuration page and ask to authorize additional permissions. That's be similar to the solution we have in place for situations some team members could face if they are not authorized for a provider of the selected project.

[jldec]

Yes, prompting at the time of the failure (instead of spinning and failing silently unless you open the console) should be good for now.

For the future, it would be good to validate the permissions as early as possible i.e. right after selecting the repo.

[jldec]

To clarify further @AlexTugarev, it would be nice to show a notification, and prompt for additional scope when the detection fails (similar to the way start-workspace does it - see image below), and then return to the configuration page.

If that is not straightforward to do, I think it would be ok for now to just unblock the "New Workspace" button as discussed in #6389 (comment), and let the error popup when the user proceeds to click on "New Workspace".