Abstract github specifics to allow support for gitlab, bitbucket, etc about dependabot-core

[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!

[greysteil]

The issue to watch on this one is #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.

[greysteil]

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

• 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)
• After that, I'd give the same treatment to GitCommitChecker
• Then I'd extract the GitHub logic in PullRequestUpdater into a Github class (as we do for PullRequestCreator)
• 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 - 801a582.

[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.

[jkniest]

@greysteil Any updates on this? :-)