Danger — Automate PR Review Rules in CI

Practical Notes

• Quant: start with 1–3 rules and expand after a week of signal/noise review.
• Quant: use --verbose for the first 3 CI runs to diagnose token/PR context issues.

Pattern: make PR policy explicit (and reviewable)

Treat your Dangerfile like any other engineering policy:

• keep the first sentence of each message actionable (what to change),
• link to the team standard (CONTRIBUTING / style guide),
• and version it with code review.

Pattern: split “hard fail” vs “soft warn”

Start with warnings (comments) to build trust, then promote the most stable checks into strict merge gates.

Troubleshooting checklist

• Confirm the CI job runs only on PRs/MRs.
• Confirm the correct token env var exists in that job.
• Run bundle exec danger --verbose locally (in a PR checkout) to reproduce.

FAQ

Q: Is Danger free? A: Yes. It’s open-source under the MIT license; you host and run it in your own CI.

Q: Do I need Ruby in my repo? A: Typically yes. Most teams run Danger via Bundler so versions are pinned per repo.

Q: How do I keep it from being noisy? A: Start with a few high-signal checks, and distinguish warnings from failures.