[dashboard/self-hosted] add Setup page

[AlexTugarev]

how to test

1. either use https://at-setup.staging.gitpod-dev.com/ or create a branch from this PR
   it should start out with a Welcome to Gitpod modal.
2. create an OAuth Application on gitlab.com (built-in auth providers are disabled in e5c443a)
3. use https://staging.gitpod-dev.com/<HOST>/callback as redirectURI on GitHub/GitLab.
4. follow the instructions of the New Git Integration modal.
5. expect to see the regular dashboard once you finished the setup of a git integration.
6. be sure to test the environment exclusively. remember, the setup process is a single user thing.

closes #3705
closes #3904
closes #3920

[gtsiolis]

Looking at this now! 👀

[gtsiolis]

Hey @AlexTugarev! This is dope. 🌟

Left some minor comments below, let me know what you think!

question: Does this only work with a self-hosted Gitlab installation?

1. I couldn't set up a GitLab integration using GitLab.com. I was getting the following errors:
   • First time, I got redirected to /sorry ....
   • Second time, I run into: The redirect URI included is not valid.
2. I couldn't set up a GitHub integration using GitHub.com. Go redirected to an empty page with a URL like /complete-auth?message=error:eyJlcnJvciI6 ...

---

Regarding UX, there's a lot of room for improvements on the first screen but this should be fine for this iteration. For example, we could use the first screen to promote a couple of features or prompt for an upgrade to a paid tier.

[AlexTugarev]

@gtsiolis, I just realized, you didn't went through the flow, because the hot to test from above was incomplete.

For preview environment we need to remove the k8s namespace from the redirect URL when testing, so it becomes: https://staging.gitpod-dev.com/<HOST>/callback

[gtsiolis]

For preview environment ...

Ah, ok. Trying again now. ➿

[AlexTugarev]

@gtsiolis, please ping me if you need help with the test setup.
I've already tackled your comments but as it would interrupt your testing, I'm waiting to push.

[gtsiolis]

Alright! /cc @AlexTugarev

1. GitLab integration works as expected. ✅
2. GitHub integration returns to the New Integration modal and prompts the user to activate the integration. ❌

Other notes:

1. The integration is being added on the Git Providers list regardless if the integration activation failed.
2. The integration is being exposed to the login options regardless id the integration activation failed.

question: Is it not possible to add a Bitbucket integration on a self hosted Gitpod instance?

[AlexTugarev]

GitLab integration works as expected. ✅

Thanks for verifying @gtsiolis!

GitHub integration returns to the New Integration modal and prompts the user to activate the integration. ❌

Could you explain how you did that?
After the initial setup, i.e. creating & authorizing with git/identity provider, you should be redirected to the dashboard.

Once the setup is done, you should not be able to see the Setup page again.

The integration is being added on the Git Providers list regardless if the integration activation failed.

That should only be true for the owner.

The integration is being exposed to the login options regardless id the integration activation failed.

That should never be the case.

[gtsiolis]

@AlexTugarev when I clicked Activate Integration after entering the Client ID and Client Secret I got redirect back to the same modal.

On the GH side, maybe I did something wrong but I tried entering both of the following as Homepage URLs:

1. https://at-setup.staging.gitpod-dev.com/
2. https://staging.gitpod-dev.com/

---

Regarding, the login page this is what I see when the GH activation fails on /integrations and /login:

Integrations	Login

[AlexTugarev]

@gtsiolis, I just checked with GItHub OAuth apps for gitpod-dev environments.

If you chose to integrate with github.com OAuth app of yours, please configure the following redirect URI. Note that the k8s namespace is missing.
https://staging.gitpod-dev.com/auth/github.com/callback

There is a reason behind that change of redirect URI and it only affects preview environments. In theory you could just reuse the suggested URL from that modal, but we have a special case, in which we reuse a single OAuth app for all preview deployments, thus need to distribute the requested based on k8s in the upstream proxy for preview environments.

From #3995 (comment), I can learn two things:

1. the urls might be wrong
2. the error OAuth error message should be integrated into the integrations modal, the same way as we now do for the signup

[AlexTugarev]

Regarding UX, there's a lot of room for improvements on the first screen but this should be fine for this iteration. For example, we could use the first screen to promote a couple of features or prompt for an upgrade to a paid tier.

@gtsiolis that's two separate thing, right? feel free to make suggestions. I was counting on you to get some input for the rough draft, which is basically made after the What's New modal.

[gtsiolis]

Taking a look at this, round two! 🥊

[gtsiolis]

Thanks for all the updates here @AlexTugarev! 🥊

We're almost there! I still can't get the GH integration on but maybe it's because I'm missing something. Let me know what you think. 💭

[gtsiolis]

FYI, I'm also working on improving the first step (currently a modal). Will open a follow-up issue once I have something ready-for-development. 🎨

[AlexTugarev]

@gtsiolis, I figured why the unverified providers were visible on Login page, even for anonymous users.

There is indeed a variance in gitpod-com, which handles it completely different. I though fa72b25 would just make sense to introduce in core as well, which changes the bits to hide not verified from the dashboard (as filtered API result)

In general, we might need to convert the compile time variance to deployment configuration, to support both cases.

[gtsiolis]

I figured why the unverified providers were visible on Login page, even for anonymous users.

Thanks for checking @AlexTugarev! Do you think it's worth opening a follow up issue for this? 🏓

[AlexTugarev]

Do you think it's worth opening a follow up issue for this? 🏓

@gtsiolis, that's solved already.

[geropl]

/werft run

👍 started the job as gitpod-build-at-setup.10

[geropl]

/werft run

👍 started the job as gitpod-build-at-setup.11

[geropl]

/werft run

👍 started the job as gitpod-build-at-setup.12

[geropl]

👍