I don’t think you need Github integration for mirroring. Gitlab can mirror/push a repository to any valid git repo out there. It’s under Settings > Repository > Mirroring. All you need is the a url and a token.
The caveat in that scenario is that mirroring is one way. So one of the repos is the primary one (eg. Gitlab), that pushes changes to the other(s). That means that you can only merge through the web interface on the primary repo. If a PR is opened on Github, you’ll do the review and when it’s ready to be merged you’ll have to do the merge locally and push it to Gitlab. When Github gets the changes will know that this is the same commit and will close the PR as merged.
+1 @pierreozoux. Yes, Github (before M$ as well) sucks but it is the daily reality of the majority of software developers for now. We have to meet them where they are ready to be met and that is largely on Github. Auto-migrate, login and mirroring all start from the integration. I would add it.
I’m not sure from your post what is your proposal. Can you make an unambiguous statement instead?
From what I understand, you’re proposing to use Github logins. As explained before, such logins are already compatible with Gitlab, Framagit, and Git Coop. Therefore it’s unnecessary to accept direct Github logins, since we would lose an opportunity to send such users to GH alternatives already.
I’m not concerned at all that the bulk of ‘open-source’ developers are on GH since most of them cannot make a difference between the former and free software in the first place. We’re interested in contributors who know the difference, so as to engage with them. The others will have to learn the difference first, probably by watching LibreHosters and sister projects mark this difference more clearly.
I’d be happy that @pierreozoux gets Gitlab admin and proceed with the proposal in post #12. Is it @mattronix who has set this up?
Just so i understand what are trying to achieve here, authentication with github?
For anything authentication related the connection has to be done at keycloak level and not gitlab level but i might not be fully understanding the goal.
But we are we not federating at the SSO level? as application-level authentication oauth or SAML will end up going though Keycloak anyway so it seems like with our topology it might be more overhead to do auth from Gitlab rather then Keycloak?
@pierreozoux do you feel the same way or do you see a limitation of Keycloak or benefit of “login with Gitlab” that I might not be aware of yet?
I guess it’s a matter of ‘advertisement’: the current info says ‘Sign in with login.libreho.st’ and offers a ‘local’ username/password login interface – this one could be removed and replaced with a single SSO button that can advertise as login.libreho.st does. In this case it might even be advantageous to redirect Gitlab sign-in page directly to login.libreho.st, yes?
I understand where your coming from but to “login with gitlab” you will then be redirected to keycloak automatically as GItlab uses keycloak as its sole auth provider meaning you enter the same flow but with an additional step which might not add any value to the user experience and increase operational management overhead of the application and failure domain of authentication services.
I like the idea of somehow making the SSO (keycloak) more appealing to the target audience.
Correction: i forgot we have local login enabled so both work.
I’d be happy to configure GitLab at git.coop to be used as a SSO server for libreho.st services if someone could let me know what would need to be done.
PS I’m replying by email as I’m unable to login here as the password reset appears not to work?
I’m not sure from your post what is your proposal. Can you make an unambiguous statement instead?
Add ‘Login from Github’ integration.
since we would lose an opportunity to send such users to GH alternatives already.
I’m interested in the ‘coming from Github already’.
I’m not concerned at all that the bulk of ‘open-source’ developers are on GH since most of them cannot make a difference between the former and free software in the first place. We’re interested in contributors who know the difference, so as to engage with them. The others will have to learn the difference first, probably by watching LibreHosters and sister projects mark this difference more clearly.
I suppose this is the kernel of it. I am concerned because I’m not interested in Librehosters becoming a sect where we dismiss ‘open source’ minded developers …
You’ve said they can learn by watching and that’s good but I’d rather they can automatically login and just talk with us on the issue tracker … that interaction has more impact. Why not also take advantage of this option? It’s an acceptable strategy in my mind …
Like, take for example the Anarchist federation https://www.vrijebond.org, they have a facebook page: https://www.facebook.com/vrijebond/. I am sure they had this argument internally - ‘should we add the facebook button’. Now my mother gets anarchism posts on her feed and I think it’s great! The Vrije bond continues to be radically anti-capitalist and maintains its integrity …
And while this discussion is potentially ‘going political’, I don’t want to block motivation for the other logins
Are you using an SSO platform at the moment or will you be using us as an SSO provider in your gitlab instance?
The SSO GitHub login link was a unexpected side effect that resulted from creating and configuring the gitdotcoop account on GitHub to enable easier syncing of repos at the request of @decentral1se.
There is still a email domain whitelist for account creation at git.coop so I don’t think that any GitHub user can sign up for an account (feel free to test this and let me know if this isn’t the case!).
Related to the email issue could you direct message me your email address i and i will in the meantime debug
I don’t believe you can start a private thread via email with Discourse so you would have to start that, I did post some more details in #librehosters-techtalk on Freenode.
Sorry I didn’t answer your question in my post above.
Are you using an SSO platform at the moment or will you be using us as an SSO provider in your gitlab instance?
There are currently no plans to use a SSO platform with git.coop.
I though @decentral1se was suggesting using git.coop as a SSO provider for libreho.st — git.coop is only open for account creation by members of Webarchitects (you can join for £1 or more) and this is not due to change.
Yes, I think it’s better since we should not use direct app login from Gitlab anymore and only use SAML through the Keycloak.
Well, please read the previous conversation, and understand why it’s not acceptable for us to make visible a link to Microsoft. Since all 3 ‘acceptable’ identity providers accept GH logins, there’s no reason why we should not support them instead of Microsoft.
Being anarchist does not preclude having different strategies. Probably the Dutch AF has no serious sysadmin in their ranks and prefer to adopt a Marxist approach to gather a critical mass – hahaha. More seriously, what they do does not concern us.
Rather the opposite: librehosters were created as a political response to the GMAFIA oligarchy, so the position is political from day one.
Our strategy is to make visible what alternatives exist, not to support the enemy. If we say the enemy is the GMAFIA, then we do not make them visible. Supporting our friends makes much more sense, hence the will to put into visibility Framagit, Git Coop (and to a lesser extent, Gitlab, since it gathered most of the GH diaspora, despite being VC-funded core business, it remains the most serious global scale alternative to GH, until it is acquired by some other giant).
It should appear obvious to each of us that making our friends visible is a viable tactic, while making the enemy visible is suicidal since the latter don’t need us to be visible as they’re the masters already, aren’t they?
I’m always puzzled at people who think that it’s good to “degooglize” Internet, but it’s OK to use GMAFIA clouds.
