🚫 Stop saying "you forgot to …" in code review
Ruby HTML
Latest commit 96ce846 Feb 22, 2017 @orta orta committed with JuanitoFatas Prepare for v4.3.0
Permalink
Failed to load latest commit information.
.github Ask Dangerfile when reporting an issue Oct 25, 2016
.vscode Support for failing on errors (#583) Sep 29, 2016
bin Specify provider to script Oct 9, 2016
danger_plugins Ensure that the Dangerfile + plugins all support the new scoped future Jul 23, 2016
lib Prepare for v4.3.0 Feb 23, 2017
spec Make danger pr & local commands recognize -h to print help Feb 23, 2017
.editorconfig Enable trim_trailing_whitespace for all files [ci skip] (#549) Sep 15, 2016
.gitattributes Set CHANGELOG merge strategy to union Feb 13, 2016
.gitignore Dump RSpec JUnit Formatter failures to a local .xml_dump_failures file Oct 9, 2016
.hound.yml Added hound config Jan 13, 2016
.rspec Remvoe duplicate RSpec CLI option (#598) Sep 29, 2016
.rubocop.yml Temporarily increasing block length rubocop config Feb 23, 2017
.travis.yml Update 2.3 to 2.3.3 and add 2.4 to CI. Dec 27, 2016
CHANGELOG.md Prepare for v4.3.0 Feb 23, 2017
Dangerfile Is version bump Should be CHANGELOG.md + lib/danger/version.rb (#604) Sep 30, 2016
Gemfile Update chandler, gitlab and add rubocop Feb 23, 2017
Guardfile Bring balance back to the rubocops - use double strings everywhere Jul 5, 2016
LICENSE Added MIT license Nov 4, 2015
README.md Update README.md Oct 22, 2016
Rakefile Improving the no token error during setup (#579) Sep 26, 2016
VISION.md Copyedit the vision statement Aug 19, 2016
appveyor.yml Revert the cork fix, make windows just run specs Jul 17, 2016
build.sh When clean building locally, print danger status locally too Jul 12, 2016
circle.yml Don't run danger on external PRs in Circle Dec 30, 2016
danger.gemspec Temporarily increasing block length rubocop config Feb 23, 2017

README.md

Danger 🚫

License Gem Travis CI

Formalize your Pull Request etiquette.


What is Danger? β€’ Helping Out β€’ Plugin Development


What is Danger?

Danger runs after your CI, automating your team's conventions surrounding code review.

This provides another logical step in your process, through this Danger can help lint your rote tasks in daily code review.

You can use Danger to codify your teams norms, leaving humans to think about harder problems.

For example?

You can:

  • Enforce CHANGELOGs
  • Enforce links to Trello/JIRA in PR/MR bodies
  • Enforce using descriptive labels
  • Look out for common anti-patterns
  • Highlight interesting build artifacts
  • Give specific files extra focus

Danger provides the glue to let you build out the rules specific to your team's culture, offering useful metadata and a comprehensive plugin system to share common issues.

Getting Started

Alright. So, actually, you may be in the wrong place. From here on in, this README is going to be for people who are interested in working on and improving on Danger.

We keep all of the end-user documentation at http://danger.systems.

Some quick links: Guides Index, DSL Reference, Getting Started and What does Danger Do?.

Sidenote: There is a pure JS version in the works, it's at the point where it can fail your build but that's about it for now, would love help there if it interests you.

I'm here to help out!

Brilliant. So, let's get you set up.

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

This sets everything up and runs all of the tests.

Theory

Danger has a VISION.md file, which sums up the ideas around what Danger is. It is the lower bounds of what Danger means. Orta has written on handling and creating Danger on the Artsy blog, too.

Documentation

The code you write may end up in the public part of the website β€” the easiest way to tell is that it is vastly overdocumented. If you are working in a space that looks over-documented, please be extra considerate to add documentation. We expect the consumers of that documentation to be non-rubyists, thus you should avoid specific jargon and try to provide duplicate overlapping examples.

Testing

So far, we've not really figured out the right way to make tests for our CLI commands. When we have done so, they've ended up being brittle. So, ideally, try to move any logic that would go into a command into separate classes, and test those. We're okay with the command not having coverage, but ideally the classes that make up what it does will.

I'd strongly recommend using bundle exec guard to run your tests as you work. Any changes you make in the lib, or specs will have corresponding tests run instantly.

Debugging

Ruby is super dynamic. One of the best ways to debug Ruby code is by using pry. We include pry for developers: when you have a problem, copy these two lines just before your problem and follow the instructions from "I Want To Be A Danger Wizard."

require 'pry'
binding.pry

Tell me of these Plugins

License, Contributor's Guidelines and Code of Conduct

We try to keep as much discussion as possible in GitHub issues, but also have a pretty inactive Slack --- if you'd like an invite, ping @Orta a DM on Twitter with your email. It's mostly interesting if you want to stay on top of Danger without all the emails from GitHub.

This project is open source under the MIT license, which means you have full access to the source code and can modify it to fit your own needs.

This project subscribes to the Moya Contributors Guidelines which TLDR: means we give out push access easily and often.

Contributors subscribe to the Contributor Code of Conduct based on the Contributor Covenant version 1.3.0.