-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a Dangerbot webservice #42
Comments
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
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 |
I like this! I'd have the keys for the on :issue do |issue|
# ...
end |
Yeah, I'm chill there, CocoaPods supports both but we always use symbols for docs |
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 |
Great idea! |
@orta On the last example, shouldn't 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. |
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. |
👍 |
Things like: Hey you have a code style issue, click here to fix it, and danger either commits to your branch with |
This sounds like a great idea, I'd be happy to help out with it. |
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 |
* 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
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. |
As of danger/peril#46 - this effectively exists in Peril. |
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. |
https://github.com/yahoojapan/hosted-danger is that other approach to running danger on a server |
Could be something I can pull off as a MVP with a few weekends I've been wanting to try rails 5
danger
in a sandbox only allowing access to the folder it's currently in.The text was updated successfully, but these errors were encountered: