Extend GitLab sync support to self-hosted instance

[MaxSchlueter]

This is done by getting rid of hard-coded "gitlab.com" URLs, instead
creating a new persistent field that stores the hostname of the GitLab
instance and constructing the URLs based on this field.

Adresses #868

[chasecaleb]

Hi, do you have a plan for dealing with the OAuth secret? The reason this only works for gitlab.com is because you need a separate OAuth integration for each GitLab instance, so unfortunately you can't just change the URL. The OAuth secret is configured at deploy time, so this won't allow using a different GitLab instance with organice.200ok.ch currently. See https://github.com/200ok-ch/organice/blob/master/.env.sample

[munen]

@chasecaleb Thank you for chiming in🙏

@MaxSchlueter Thank you for giving it a shot and providing a PR🙏To the best of my understanding, @chasecaleb is right. I don't see how to accommodate that requirement on the official instance.

I suppose supporting self-hosted Gitlab instances implies a self-hosted organice instance. If so, we could add a few lines of documentation for it. I suppose that's not so bad. Anyone willing and capable to self-host a non-trivial application as Gitlab is likely capable and willing of self-hosting a single-page application or at least the official Docker image.

[branch14]

Here is an idea that I briefly discussed with @munen, and we think it's feasible.

The OAuth secret mentioned by @chasecaleb is currently injected into the build. (In the code it looks like it is read from an env var, but it actually is read from the .env file during build time.) This happens here:

organice/src/sync_backend_clients/gitlab_sync_backend_client.js

Line 17 in c948643

clientId: process.env.REACT_APP_GITLAB_CLIENT_ID,

My suggestion is the following: The sign-in form for Gitlab gets a second input field which takes the OAuth secret (aka Gitlab app token, aka client id). The second input field is disabled as long as the first input field holds a repo url for gitlab.com. If the user enters a repo url for a Gitlab instance other than gitlab.com, the second field is enabled and a token is required.

@chasecaleb What do you think?

@MaxSchlueter Would you like to give this a shot?

[chasecaleb]

Yeah, that's how I would do it too. So long as you think it's worth the complexity then I think that's the right approach.

[MaxSchlueter]

@MaxSchlueter Would you like to give this a shot?

Sure, thanks for chiming in. I haven't worked with OAuth secrets before, but wouldn't the client secret (REACT_APP_GITLAB_SECRET) as a third input field be needed as well?

[munen]

@MaxSchlueter Yes, both REACT_APP_GITLAB_CLIENT_ID and REACT_APP_GITLAB_SECRET will have to be overridden in the login form.

[kephale]

I'm super excited about this PR!

[munen]

@kephale Would you like to take it over? There's one small step missing that's discussed starting here: #874 (comment)

[kephale]

I can check, but it was really easy to just pull these changes into the latest main then (at least) just run off my own instance with my instance's .env info.

It would certainly be better to be able to resolve the secret stuff at runtime instead of build time, but even without that, this solved my use case.

[munen]

It would certainly be better to be able to resolve the secret stuff at runtime instead of build time, but even without that, this solved my use case.

It works for users self-hosting Gitlab and self-hosting organice, now. But not everyone is self-hosting organice. So adding two more fields to the login will be the right way to go forward.

[kephale]

Some effort in this direction, but not working yet https://github.com/kephale/organice/tree/self-host-wrapup