Create a Dangerbot webservice #42

Closed
orta opened this Issue Jan 30, 2016 · 15 comments

Comments

Projects
None yet
7 participants
@orta
Member

orta commented Jan 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@orta

orta May 17, 2016

Member

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
Member

orta commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jeroenvisser101

jeroenvisser101 May 17, 2016

Member

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

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

jeroenvisser101 commented May 17, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@orta

orta May 17, 2016

Member

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

Member

orta commented May 17, 2016

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

@jeroenvisser101

This comment has been minimized.

Show comment
Hide comment
@jeroenvisser101

jeroenvisser101 May 17, 2016

Member

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.

Member

jeroenvisser101 commented May 17, 2016

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

This comment has been minimized.

Show comment
Hide comment
@KrauseFx

KrauseFx May 17, 2016

Member

Great idea!

Member

KrauseFx commented May 17, 2016

Great idea!

@marcelofabri

This comment has been minimized.

Show comment
Hide comment
@marcelofabri

marcelofabri May 18, 2016

Member

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

Member

marcelofabri commented May 18, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@justMaku

justMaku Jun 2, 2016

Member

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.

Member

justMaku commented Jun 2, 2016

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

This comment has been minimized.

Show comment
Hide comment

sylvek commented Aug 4, 2016

👍

@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Aug 15, 2016

Member

Came up in discussion:

screen shot 2016-08-15 at 6 05 35 pm

What if you could actions to handle this stuff

Member

orta commented Aug 15, 2016

Came up in discussion:

screen shot 2016-08-15 at 6 05 35 pm

What if you could actions to handle this stuff

@KrauseFx

This comment has been minimized.

Show comment
Hide comment
@KrauseFx

KrauseFx Aug 15, 2016

Member

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)

Member

KrauseFx commented Aug 15, 2016

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 comment has been minimized.

Show comment
Hide comment
@k0nserv

k0nserv Aug 21, 2016

Member

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

Member

k0nserv commented Aug 21, 2016

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

@k0nserv

This comment has been minimized.

Show comment
Hide comment
@k0nserv

k0nserv Aug 25, 2016

Member

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

Member

k0nserv commented Aug 25, 2016

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

JuanitoFatas added a commit that referenced this issue Sep 17, 2016

Support GitHub's "squash and merge" for danger local
Merged PR log has these formats:

1. Merge pull request #42
2. summary (#42)

Add supports for 2.

orta added a commit that referenced this issue Sep 17, 2016

Improves "danger local" Pull Request finding (#559)
* Add pry-byebug for debugging

* Support GitHub's "squash and merge" for danger local

Merged PR log has these formats:

1. Merge pull request #42
2. summary (#42)

Add supports for 2.

* Refactor logic into MergedPullRequestFinder

* Refactor logic into RemoteFinder

* Add specs for MergedPullRequestFinder

* Default Pull Request ID to "" when not specified

* Add a changelog

* Address rubocop and target ruby version >= 2.1

* We support Ruby 2.0

@wongzigii wongzigii referenced this issue in Quick/Quick Nov 8, 2016

Merged

Bot for Quick #634

7 of 9 tasks complete
@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Mar 23, 2017

Member

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.

Member

orta commented Mar 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@orta

orta Apr 3, 2017

Member

As of danger/peril#46 - this effectively exists in Peril.

Member

orta commented Apr 3, 2017

As of danger/peril#46 - this effectively exists in Peril.

@orta

This comment has been minimized.

Show comment
Hide comment
@orta

orta Aug 20, 2017

Member

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.

Member

orta commented Aug 20, 2017

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 orta closed this Aug 20, 2017

@orta orta referenced this issue in danger/peril Apr 22, 2018

Open

Peril Highlights #235

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment