Using DangerJS with GitLab/BitBucket

[k15a]

Hey,

is there a way how I can use DangerJS for GitLab with the GitLab CI. Otherwise, is it possible to add support for GitLab and GitLab CI and where could I start to implement it?

[orta]

Can't use it for GitLab today.

However, I built Danger JS with the same abstractions used in Danger Ruby, which does. Though, I'd wait till #395 lands before starting though, it's a massive PR.

So the general TODO:

• Add support for new ENV vars
• Create a new object which conforms to Platform
• getPlatformForEnv will need to figure out whether it's GH/GL project
• Let a CI source determine if they can work with GitLab (I think there's already something in there )
• Extend DangerJSONDSL / DangerDSL with a GitLab DSL
• Cover this stuff in tests, as this repo runs on GitHub and it's possible we could accidentally break it
• Note: The markdown rendering is different in Danger Ruby GitLab
• Lots of other context in Gitlab danger#299

[orta]

#395 is now merged 👍

[jchv]

Just FYI, I'm interested in working on this. Not 100% sure how far I'll get.

[k15a]

@jchv Nice that you want to give it a shot. Maybe some useful information I figured out:

• GitLab doesn't have the concept of merge requests for now so you have to be a little bit hacky and figure out the corresponding merge request to a pipeline on your own. Take a look at the ruby integration and copy the logic from there.
• Otherwise, the codebases are really close to each other so you can figure a lot of things out when you watch the Danger Ruby PR.

[jchv]

Yeah, luckily I have some of the background in mind already. I think working backwards to get the MR is fine; GitLab will probably eventually add CI events for MRs, at which point we can do this properly. Until then, there was a hack that someone mentioned in a Danger Ruby thread that filled the gap using build triggers such that Danger didn't have to be modified; that way, end users can at least make sure MRs always get hit until the CI itself supports MR events.

[LukeSheard]

Anyone got any idea how much effort it would be here to abstract it enough to support BitBucket server / hosted? Happy to lend some hours.

[orta]

Abstraction wise it should be just as much work to support GitLab as it is for BitBucket - the original Danger Ruby PRs for that are danger/danger#481 and danger/danger#496

[orta]

I've got some more work coming up which makes this easier as it decouples the git DSL from the github platform also

[orta]

That work got merged two days ago: #473

[keplersj]

I'm interested in pursuing this. Are there any blockers still before this can be done?

[orta]

Nope, no blockers

[keplersj]

So is the big thing to write the DSL for GitLab that gives access to the GitLab API?

[orta]

Yeah, that's a good place to get started - I'd advise starting by finding a good npm module for the GitLab API then making something which conforms to Platform from that

[orta]

DSL wise, I'd ideally like to feel like the GitHub DSL e.g. the minimum is:

danger.gitlab.mr = exactly the MR JSON from the API
danger.gitlab.utils = util funcs 
danger.gitlab.commits = commits from the GitLab API

After that you can expand it however makes sense