Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Create a Dangerbot webservice #42
Could be something I can pull off as a MVP with a few weekends I've been wanting to try rails 5
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
@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'll try to get a simple POC of this working this weekend because such solution solves my problem with Bitbucket + Bamboo.
referenced this issue
Jun 9, 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