Danger: Create a Dangerbot webservice

[orta]

Could be something I can pull off as a MVP with a few weekends I've been wanting to try rails 5

• A bit like the Facebook mention bot
• Pay £5 per user account (e.g. pay once for ORStackView and ARAnalytics) or an org (Eigen, Eidolon, Energy etc ) to allow it to do PR messages / status updates.
• Runs danger in a sandbox only allowing access to the folder it's currently in.
• Would make it easier to set up for orgs, just tick a box and add a Dangerfile.
• Could make a Dangerfile for a collection of repos.

[orta]

So the foundations here would be a repo that anyone can click a heroku button, have it install an instance on heroku in a way that Fastlane's Boarding does

You'd need to pass an env var of your DANGER_GITHUB_API_TOKEN and it will respond to webhooks from github, interesting ones are

• issues
• issue_comment
• pull_request_review_comment
• pull_request
• push

However, in theory, we can support _all_ of the web hook notifications via a DSL that supports something a bit more generic, so you could do this:

# Sometimes its a README fix, or something like that - which isn't relevant for
# including in a CHANGELOG for example
has_app_changes = !modified_files.grep(/lib/).empty?
has_test_changes = !modified_files.grep(/spec/).empty?

[...]

on "issues" do |issue|
  # lint the description
end

on "issue_comment" do |issue_comment|
  # lint the description
end

_If_ this DSL works well, I would also propose that we move to moving our current work to make the current default root context not important, and force everyone to migrate to use a PR context too. E.g.

on "pr" do |pull|
  # Sometimes its a README fix, or something like that - which isn't relevant for
  # including in a CHANGELOG for example
  has_app_changes = !modified_files.grep(/lib/).empty?
  has_test_changes = !modified_files.grep(/spec/).empty?
end

[jeroenvisser101]

I like this! I'd have the keys for the on call symbolized, i.e.:

on :issue do |issue|
  # ...
end

[orta]

Yeah, I'm chill there, CocoaPods supports both but we always use symbols for docs

[jeroenvisser101]

Sounds like a plan. I think the setup would be way easier with a heroku button since that'd allow us to explain what to do for the TOKEN in the app.json.

[KrauseFx]

Great idea!

[marcelofabri]

@orta On the last example, shouldn't modified_files be a property/method of pull?

Maybe we should think about adding support to "multiple Dangers". For example, I could have one instance of Danger as a Service, but I'd like to have Danger running after my PR job so I can use the xcodebuild log. Today, one Danger would overwrite the other. I don't know how important is this use case though.

[justMaku]

I love the idea, it's definitely a step into a right direction for #213 and I believe it could be nicely solved by decoupling Pull Request from both CISource and RequestSource (#226)

I'll try to get a simple POC of this working this weekend because such solution solves my problem with Bitbucket + Bamboo.

[sylvek]

👍

[orta]

Came up in discussion:

What if you could actions to handle this stuff

[KrauseFx]

Things like: Hey you have a code style issue, click here to fix it, and danger either commits to your branch with rubocop -a or submits a PR to your branch (depending on the available permission)

[k0nserv]

This sounds like a great idea, I'd be happy to help out with it.

[k0nserv]

I've been thinking a bit about the token and a way to move the token away from the public eye. I'd suggest we include the hash of the Dangerfile as an argument when running danger via the service. We can then refuse to run if the hash doesn't match that of the Dangerfile used. This way the github/gitlab token can stay secret and someone couldn't just create a PR that echoes the token in the danger file. The hash of the file could be kept in the secrets of the CI systems and sent along with the call invoking danger.

This feature does make it harder to use Danger, but it increases security and removes the issues accossiated with a public token. Maybe it could be optional

[orta]

This now exists for DangerJS, I won't build it for Ruby - https://github.com/danger/peril

Someone is welcome to look at this for Ruby though.

[orta]

As of https://github.com/danger/peril/pull/46 - this effectively exists in Peril.

[orta]

OK, Peril is now in production for Artsy and CocoaPods. Someone is welcome to try do it themselves in Ruby, but I'm going to close this.

[orta]

https://github.com/yahoojapan/hosted-danger is that other approach to running danger on a server