# Danger: Automating Pull Request Etiquette in Ruby

> Danger runs during CI and applies rules you write to the metadata of a pull request, so reviewers stop repeating the same comments. The Ruby gem is MIT licensed and its end-user documentation lives on a separate site.

**danger/danger** — 🚫 Stop saying "you forgot to …" in code review (in Ruby)

- Repository: https://github.com/danger/danger
- Website: https://danger.systems
- Stars: 5,689 · Forks: 489
- Language: Ruby
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/danger-danger

## The review comments nobody wants to type twice

Every team has a list of things a reviewer always says. Add a changelog entry. Link the ticket. Give the pull request a descriptive title. Check that the new file is not a duplicate. These are not judgement calls, they are checks, and a human doing them by hand is a waste of a human. Danger exists to move that class of comment out of the reviewer's head and into a file that runs during CI. The README puts it plainly: Danger runs during your CI process and gives teams the chance to automate common code review chores, letting humans think about harder problems. The audience is therefore a team that already has continuous integration, already has a review culture with agreed norms, and is willing to write those norms down as code. It is not aimed at a solo developer pushing straight to a branch, and it is not a linter. A linter reads your source. Danger reads the pull request: its title, its body, its labels, the files it touches, and the build artifacts attached to it. That distinction is the whole design.

## What Danger actually sees when a pull request opens

Danger is a Ruby program invoked from a CI job. It talks to the hosting provider's API (GitHub, GitLab or Bitbucket among the topics listed for the repository), pulls back a structured view of the current pull request, and hands that view to your rules. Your rules live in a file called a Dangerfile, written in Ruby against a small DSL. The DSL exposes the pull request metadata and a set of reporting functions, so a rule reads roughly like: if this condition holds about the pull request, post this message. The README frames the project as glue, offering useful metadata and a comprehensive plugin system to share common issues, which is the honest description. Danger itself does not know what a changelog is. It knows how to fetch a list of changed files and how to leave a comment. The knowledge of your conventions sits in the Dangerfile you write. That split explains both the project's flexibility and its cost: there is no rule set to switch on, so a new user gets a framework and an empty file. The repository also ships a danger_plugins/ directory and the README links to a plugin development guide, which is the intended path for packaging a rule set that several repositories share.

## Installing the gem and writing a first rule

The README is explicit that the end-user documentation lives at danger.systems, with a getting started guide, a DSL reference and a guides index. The repository README is written for people improving Danger itself, so the first thing to understand is that the install instructions you want are on the website, not in the README. What the repository does show is the shape of a Ruby project: a Gemfile, a gemspec, and a Dockerfile for running the tool in a container such as GitHub Actions. In a project that uses Bundler, the gem is added to the Gemfile and installed with Bundler. The README does not print the Gemfile line, so copy the exact requirement from the getting started guide rather than guessing a version.

```bash
bundle install
```

After that, a Dangerfile sits at the root of the repository. The README's debugging section shows the two lines contributors use to poke at a running process, require 'pry' followed by binding.pry, which is also the fastest way to inspect what the DSL exposes while you are writing your first rule. The repository's own development loop is separate from using the gem:

```sh
git clone https://github.com/danger/danger.git
cd danger
bundle install
bundle exec rake spec
```

Those four commands are for working on Danger, not for adopting it. They compile the gem's own test suite. If you are evaluating Danger as a user, the equivalent first step is to read the getting started guide, add the gem through Bundler, write one rule in a Dangerfile, and run it in a CI job against a throwaway pull request. Expect your first run to fail on permissions before it fails on logic: the CI job needs a token with enough access to read the pull request and post a comment.

## Where Danger stops being the right tool

The failure modes here are structural, not bugs. First, Danger cannot enforce anything. It reports. A rule that says a pull request must link a ticket produces a comment, and a comment can be ignored. Turning a report into a gate is a CI configuration decision, and the documentation set does not make that decision for you. Second, the rules are Ruby. A team without Ruby experience is asking its members to learn a language to write a changelog check, and the README's guidance for contributors, that documentation should avoid specific jargon and provide duplicate overlapping examples because consumers are expected to be non-Rubyists, is an admission that the DSL is the hard part for newcomers. Third, a Dangerfile is code with no test harness by default. The README notes that the project has not figured out a good way to test its own CLI commands and that such tests ended up brittle, recommending that logic be moved into separate classes that can be tested. That advice applies to your Dangerfile too: a rule that grows conditionals will grow bugs, and a broken rule that fails open silently stops protecting anything. Fourth, running Danger requires CI to have network access to the hosting provider and a credential with write access to the pull request. In locked-down environments that is a real negotiation, not a configuration flag. Finally, Danger is a poor fit for anything that needs to read code semantics. It sees file paths and diffs, not an abstract syntax tree. If your rule is about code structure rather than pull request structure, a linter or a static analysis tool is the correct layer.

## Danger against a plain CI script and against linters

The obvious alternative is a shell script in the CI configuration that calls the hosting provider's API with curl, checks a condition, and posts a comment. The difference in approach is the API surface. A curl script must handle pagination, authentication, the shape of the provider's JSON, and the comment format for every check you add. Danger wraps that surface behind a DSL and a plugin system, so the provider-specific code lives in the gem and the plugin rather than in your repository. The cost is a Ruby runtime and a dependency you do not control. The second alternative is a linter such as RuboCop, which the repository itself configures through .rubocop.yml and .rubocop_todo.yml. RuboCop reads your source files and reports style and correctness issues; Danger reads the pull request and reports process issues. They overlap only in that both can fail a build. A team that wants to enforce code style should reach for RuboCop. A team that wants to enforce that a changelog was updated, a ticket was linked, or a label was applied should reach for Danger. Choosing Danger to do a linter's job means writing pattern matching against diffs by hand, which is the worst of both.

## Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-07-29, the same day as the 9.6.1 release. The release history shows 9.6.0 on 2026-06-17 and 9.5.3 on 2025-07-04, so the cadence is not uniform: a year passed between 9.5.3 and 9.6.0, then two releases in six weeks. Treat the gem as a dependency you pin and upgrade deliberately rather than one that moves weekly. The upgrade cost is concentrated in the DSL and in the plugins you depend on, both of which are versioned with the gem. The repository's own tooling gives a hint about how tightly the project couples to its ecosystem: the Dockerfile builds on ruby:3.2-alpine, installs build-base for the builder stage, and adds git and p7zip to the runtime image, with BUNDLE_WITHOUT set to development:test. If your CI runs the container image, that is the environment your Dangerfile executes in, and a rule that shells out to a tool not in that image will fail there even if it passes locally. On licensing, the project is MIT, which the README describes as giving full access to the source code and the right to modify it to fit your own needs. That is permissive, and it means a Dangerfile you write is yours. It says nothing about the licences of the plugins you pull in, which are separate packages and should be checked individually. Nothing here is legal advice; read the LICENSE file in the repository for the actual terms.

## Conclusion

Danger suits teams with repeated review chores and a CI job that can run Ruby. It is the wrong tool for a solo repository with no CI, or for teams that will not maintain a Dangerfile. Before adopting it, read the getting started guide at danger.systems, check which CI provider the project supports in the guides, and confirm the Ruby version your CI image provides against the gemspec. The repository's own README points maintainers at bundle exec rake spec, not at end users.

## FAQ

### What is Danger and what does it do?

Danger is a Ruby program that runs during CI and automates common code review chores by applying rules you write to a pull request's metadata. The README describes it as formalizing pull request etiquette so humans can focus on harder problems.

### How do I install Danger?

The README states that end-user documentation lives at danger.systems, which hosts the getting started guide. The repository shows the gem is a Ruby package managed with Bundler, so it is added to a Gemfile and installed with bundle install.

### Does Danger work with GitHub, GitLab and Bitbucket?

The repository's topics list github, gitlab and bitbucket alongside ci providers, and the README says Danger runs during your CI process. The guides index at danger.systems is where the provider-specific setup is documented.

### Can I run Danger in Docker or GitHub Actions?

The repository contains a Dockerfile whose labels describe it as running danger in a docker container such as GitHub Actions, with an entrypoint of bundle exec danger. It builds on ruby:3.2-alpine and installs git and p7zip in the runtime image.

## Sources

- [danger/danger on GitHub](https://github.com/danger/danger)
- [License: MIT](https://github.com/danger/danger/blob/master/LICENSE)
- [Project website](https://danger.systems)
- [README](https://github.com/danger/danger/blob/master/README.md)
- [Releases](https://github.com/danger/danger/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/danger-danger