Discussion: Supporting other hosting sites (Gitlab, Bitbucket)

[bmeverett]

First of all, thank you so much for this app!

Second, there are other hosting sites that people may use to manage their code or my use in a workplace setting. Is your vision for this project to support any of those? I know that it would be a significant amount of work and results may vary depending on the different APIs that are offered.

If not supported in your vision/plans would you support a PR/Fork of this repo for that purpose.

Thanks again!

[rnystrom]

I would absolutely love to support this, but it’s honestly just not a high priority for me because I don’t use any other platforms. Very happy to review proposals and PRs to integrate, and since it’s open source I’m all about forking to work with other platforms!

_{Sent with GitHawk}

[Sherlouk]

I think the main issue is that everything is so tightly coupled to the GithubClient class, and that has quite a number of extensions for all it's actions - What we'd really need is a protocol which is used and GithubClient happens to conform to allowing it to be easily swapped out for a different service (GitLab, etc)

One thing we could do actually very easily is add GitHub Enterprise support. Their API is essentially the same except for the login flow, but a lot of people on the App Store actually charge extra for the functionality!

[BasThomas]

I’m not sure if it’s that easy to support Enterprise though. At work, we have Enterprise self-hosted and I wouldn’t be able to connect without using a VPN.

[Sherlouk]

@BasThomas That's a pretty common problem, but that just comes down to proper error handling. Can't connect to the host? then tell the user!

It's completely out of our control whether the user has access to the enterprise instance, we can't hack our ways through the internet cables 😂

[BasThomas]

No obviously. Of course telling the user would “just work”. 😅

[BasThomas]

@Sherlouk have you been thinking on how we could easily add Enterprise support? Might be something I want to look into. :)

[Sherlouk]

I've been thinking about it, wouldn't say I've been actioning it though - you're more than welcome to pick it up! I don't have an enterprise instance to test against regardless (darn GitLab users at work)

[BasThomas]

I would really like to work on this (adding GH Enterprise support), and have some time to do so next week. No idea where to start though, let me know if you have any ideas about it!

[Sherlouk]

So I'd say the absolute first thing is we need to get rid of all GitHub.com references, primarily for things like opening accounts etc

Ultimately we want to get it back to where we have a single "base url" which is used for all calls

The GitHub API is pretty consistent across enterprise/normal so just changing the base URL should get us 90% of the way. IIRC the login flow is a bit different as well, but can't remember off the top of my head.

The only reason why I've not moved on with this is getting an enterprise instance to test with! Shouldn't be too bad, just a little refactoring

[BasThomas]

Ugh, totally forgot / didn’t get to this that week. 😐

_{Sent with GitHawk}

[rnystrom]

I’ve been getting more and more asks for enterprise support. Agree with @Sherlouk that as long as we have graceful error handling, it shouldn’t be too difficult since the APIs are the same (right?).

Any idea specifically what needs to change? Eg with the login flow, is the auth different? For the rest, is it just a different base url?

_{Sent with GitHawk}

[Sherlouk]

Yea I think most of the (good) enterprise solutions are all paid 😬

I do believe a standalone piece of work here is to just get to a point where we have a single Base url - we reference github.com directly in so many places! This obviously won't work with enterprise!

The login flow is a bit different because it can deal with a companies own login structure but I'm not entirely familiar with github exact solution (only gitlabs)

But I think step one is let's get a base url in, and load urls for things like user profiles from the GQL endpoint rather than assuming it's /user as we do now (fixes some of our bugs) no references to github.com! Then we can work out the next step!

_{Sent with GitHawk}

[BasThomas]

What would also be interesting about adding Enterprise Support, is that there might be differences in the currently supported features between the two. That would also be something we would like to keep in mind when adding this.

_{Sent with GitHawk}

[Sherlouk]

100% agree there! I think for the most part (and especially with what we currently support) there is pretty solid parity but there are definitely going to be parts where they're different

If we go down the approach of an enum of sorts in the account manager (as talked about in 1119) we could quite easily start adding feature flags to supported clients, an over-simplified example:

enum Clients {

    case github
    case githubEnterprise

    var doesSupportProjects: Bool {
        switch self {
        case .github: return true
        case .githubEnterprise: return false
        }
    }
}

[BasThomas]

Yes, I think that would be the right approach. Also, love the code highlighting @rnystrom!

_{Sent with GitHawk}

[BasThomas]

I think I've said this before, but will be taking another stab at this next week during a hackweek at work. Super excited about this :)

[vassudanagunta]

With GitHub turning into Microsoft GitHub, it would help so many users if GitLab were supported. :)

[rnystrom]

@vassudanagunta more than happy to review some proposals and PRs on how to make it work!

_{Sent with GitHawk}

[vassudanagunta]

Gotcha! I'm busy fomenting a rebellion 😉 . We might be able to steer some developers your way as part of an effort to make GitHub alternatives more viable.

[BasThomas]

I'm going to close this for now as we've attempted to support GitHub Enterprise and saw that this was near to impossible due to different versions. I don't see GitHawk supporting other websites anytime soon either, nor have I seen requests for it.

Feel free to open a new issue if you feel we should try to tackle this in the future.