docs/guides/faq.md
Yep! Use danger local. If you want to get into a debug REPL, use danger local --pry. You can find more on the troubleshooting guide
You can tell Danger to ignore a specific warning or error by commenting on the body of your code review body:
> Danger: Ignore "Developer Specific file shouldn't be changed"
Then Danger would not show that message, and would not fail the build if it were the only fail.
For any significant number of repos we recommend you package your Dangerfile in a gem, release it and use it via danger.import_dangerfile(gem: "name"). This allows you to specify versioned plugin dependencies and share rules.
See ruby-grape/danger for an example.
Alternatively you can also use a shared Dangerfile and import it via danger.import_dangerfile(github: "org/repo"). Assuming Danger can reach the other repo, she will download the Dangerfile from that repo and parse it in-place.
This gives access to the same local and other environment variables.
You can have each instance of Danger running on a different CI provider and even doing different validations. An use case would be:
basic runs on a Linux environment (such as Circle CI) and validates the PR itself (title, etc)compilation runs on a Mac after running unit tests for your iOS app and comments about warnings, test failures, etcuitests runs on a Mac after running UI Unit tests and comments about test failuresbundle exec danger --danger_id=unit_tests
You can use --new-comment to do this
bundle exec danger --new-comment
If you have Danger running on a OSS project, you should be using a token that is publicly available on CI or external contributors cannot have danger rules applied.
You work around this security hole by making the bot have no access to any repos. Meaning that the only thing the bot can do is comment on OSS projects.
If you need to give the access to your bot to particular private repos or rights to certain resources, then you can only make Danger run on branches. These are logical rules for safety by CIs with env vars I'm afraid.
If this is a blocker, there's always Peril.
Yep, here is an example of moving to support that from the Ruby Grape project.
When we were in the naming process of Danger, we went through a lot of names. In the end, it got named after Gem "Danger" McShane, who was involved in both the copy and the concept. While not a programmer herself, she's helped out with trying to understand the personality behind the project. Danger, the project, is a female, northern UK, command-line app into 80's punk/indie. Inspired by community efforts like the Haçienda / Factory Records.
<iframe src="https://embed.spotify.com/?uri=spotify%3Auser%3Aortatherox%3Aplaylist%3A39vTSdxtIKzpEybyvTs3Ll" width="300" height="380" frameborder="0" allowtransparency="true"></iframe>Understandably, applying a gender to a genderless concept comes with it's own complications. To make it worse, female genders tend to be applied towards "digital assistants" which should raise questions on outdated-but-still-persisting gender stereotypes and patriarchical power structures. There is no answer that can completely absolve the disconnect I'm afraid.
Try logging in to your account that is writing the messages, it's possible that your account has triggered the bot detection algorithm on GitHub. This means that messages are sent correctly, but do not show up for anyone except the sender. This makes it more or less impossible to detect.
Because we recommend not adding your bot to your OSS project, Danger will not be able to post status updates on a PR. A status update is the green/red/yellow dots at the end of your PR page. This does not affect Danger's ability to comment, and fail your CI build, so you are fine to ignore the message.