Name: danger
Owner: MercadoLibre
Description: Stop saying "you forgot to ?" in code review
Created: 2016-07-26 16:53:27.0
Updated: 2018-04-26 00:23:32.0
Pushed: 2016-07-26 16:24:53.0
Homepage: http://danger.systems
Size: 853
Language: Ruby
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
Formalize your Pull Request etiquette.
What is Danger? • Helping Out • Plugin Development
Danger runs after your CI, and gives teams the chance to automate common code review chores.
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.
Danger simply provides the glue to let you build out the rules specific to your team's culture. Offering a lot of useful metadata, and a comprehensive plugin system to share common issues.
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 / improving on Danger.
We keep all of the end-user documentation inside http://danger.systems.
Some quick links: Guides Index, DSL Reference, Getting Started and What does Danger Do?.
Brilliant. So, let's get you set up.
clone https://github.com/danger/danger.git
anger
le install
le exec rake spec
This sets everything up and runs all of the tests.
Danger has a VISION.md file, this sums up the ideas around what Danger is. It's the lower bounds of what Danger means. Orta has written on handling, and creating Danger on the Artsy blog too.
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 avoid specific jargon and try to provide duplicate overlapping examples.
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 brittle. So ideally, try to move any logic that would go into a command into separate classes, and test those. We're OK with the command not having coverage, but ideally the classes that make up what it does do.
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.
Ruby is super dynamic, one of the best ways to debug 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.”
ire 'pry'
ing.pry
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 of 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.