Dependabot-core: Abstract github specifics to allow support for gitlab, bitbucket, etc

[riconnon]

Would be nice to make the repository provider modular to allow support for other options (eg. gitlab or bitbucket)
I think it shouldn't be too difficult to make a generic "git repo client" class which presents the required features for dependabot-core on all of the above.

[greysteil]

Agreed! If you or anyone else wants to take this on, the best approach would be to go concern by concern:

• [x] I would start with the MetadataFinders base class, because this is already close to being provider-agnostic (it just needs to start receiving a credentials hash, rather than a GitHub client, and use that hash when instantiating clients)
• [x] After that, I'd give the same treatment to GitCommitChecker
• [x] Then I'd extract the GitHub logic in PullRequestUpdater into a Github class (as we do for PullRequestCreator)
• [x] Then, in no particular order, make the FileFetchers base class and the PullRequestCreator base class provider agnostic

No reason why PRs couldn't be merged on a concern-by-concern basis.

I'm not totally convinced that a "git repo client" is the way to go on the above, because there'd be a lot f data wrangling required that might be simpler to do close to where the data is being used (see the MetadataFinders base classes for an example), but I wouldn't be adverse to it if it worked and was well tested.

[riconnon]

As far as I can tell there is a difference between the way MetadataFinders interacts with a git repo and all of the other classes since MetadataFinders is interacting with the repo of the dependency where the rest are interacting with the repo of the target project.

I am mainly interested in dealing with target projects on gitlab for the time being (but ultimately it's best if everything is as agnostic as possible)

[greysteil]

Yeah, exactly - MetadataFinders have needed to know how to interact with other providers for ages. I've just cleaned them up to not treat GitHub any differently to any other provider, though - https://github.com/dependabot/dependabot-core/commit/801a58210dc8e85e327a14d7aa0e3a9d72c425e4.

[nesl247]

Definitely interested in seeing this as my company is preparing to move to GitLab. Wasn't in the plan when we looked at Dependabot, but it is now.

[nesl247]

@greysteil Is this on the roadmap at all for you guys? We're actually in the process of migrating, and will be finishing up this week.

[greysteil]

Looks like the information on this has ended up being split between two issues - sorry about that. On GitLab support, I wrote up our position here a couple of weeks ago - the TL;DR is that it's not on the short-term roadmap. I'd love to be able to, but I just can't justify the work required on it financially at the moment :-(

[nesl247]

Thanks for the update. If I have any comments I'll keep it to the other issue to leave this one about the code changes specifically.

[greysteil]

Good news: everything except the PullRequestUpdater now works with GitLab, and there's a script here that you can use to run dependabot-core against gitlab.com (self-hosted support should be pretty easy to add too).

I'll be adding GitLab support to Dependabot itself (rather than just the core logic) in the next month or so. 🎉

Give it a go and let me know what you think!

[jkniest]

@greysteil Any updates on this? :-)

[greysteil]

The issue to watch on this one is https://github.com/dependabot/dependabot-core/issues/399.

Unfortunately I didn't get to adding GitLab support when I wanted to - instead I added Go and .NET support, and integrated with GitHub's security alerts.

My next three big things are tools for maintainers, vgo support, and GitLab. It's definitely coming - apologies for the delay.