-
-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extend GitLab sync support to self-hosted instance #874
base: master
Are you sure you want to change the base?
Conversation
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.
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 |
@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. |
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
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? |
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. |
Sure, thanks for chiming in. I haven't worked with OAuth secrets before, but wouldn't the client secret ( |
@MaxSchlueter Yes, both |
I'm super excited about this PR! |
@kephale Would you like to take it over? There's one small step missing that's discussed starting here: #874 (comment) |
I can check, but it was really easy to just pull these changes into the latest 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. |
Some effort in this direction, but not working yet https://github.com/kephale/organice/tree/self-host-wrapup |
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