Skip to main content

Danger

Linting Merge Requests with Danger​

What is Danger? In the project's own words:

Danger runs during your CI process, and gives teams the chance to automate common code review chores.

This provides another logical step in your build, 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.

This happens by Danger leaving messages inside your PRs based on rules that you create with JavaScript or TypeScript.

Over time, as rules are adhered to, the message is amended to reflect the current state of the code review.

It is a library originally written in Ruby, which started internally at Gitlab itself as a way to make some of the more common quality checks, suggestions, and comments on may leave on a merge request commonly more automated, leaving developers to worry about the more complex issues that may be present in the MR.

How does it work?​

Danger will run as a pipeline job in our Gitlab CI, alongside the other linting related jobs in the Code Linting stage of the pipeline. It will only run against Merge Requests.

Danger running on an MR pipeline

Whenever an MR is opened, and changes are pushed up to it, Danger will evaluate the changes and run tests against them. If any tests identify any issues or things of interest, Danger will write a comment on the MR itself, via it's dangerjs Gitlab bot account. The comments will consist of messages, warnings, and/or failures.

A message is more just a prompt to pay attention to something, or to provide useful hints.

A warning is to be treated the same as any other developer comment, not a linter warning. You should address these issues, as it is very likely that what you are being warned about has come up in other MRs time and time again and we've just decided to automate it.

A fail will outright block the MR, by failing the Danger pipeline job itself. These will be rare and reserved for only the most serious issues that we don't want to leave to chance of them being missed.

Here's an example

If any new changes are made to the MR, Danger will not post new comments, it will instead just edit its existing comment, thus avoiding spamming the MR. Note, that it can be however configured to post new comments, or delete and re-post its comment following changes.

The Dangerfile​

To configure Danger, we just edit the dangerfile which you can read more about here. It uses TypeScript and Danger's own DSL (Domain Specific Language), which provides for a number of included methods to access merge request related changes in git as well as the data about the MR we get from Gitlab itself.

You can find examples of how this all comes together in practice on Danger's own website, or by simply looking at our own dangerfile and pipeline.

Writing rules and testing Danger locally​

You will need a bit of setup before you begin.

Start off by getting familiarised with Danger's CLI by running npx danger --help, as all of its documentation is there and not so much on the website (annoying, yes).

You will be running npx danger pr to test changes locally against MR's in Gitlab, without posting an actual comment to the MR itself.

I suggest you avoid using npx danger local as our local dev environment and the Gitlab CI are not the same.

You will need to set 3 environmental variables, by exporting them to your local dev environment so they can be accessed via your terminal:

  • DANGER_GITLAB_HOST: 'git.neds.sh'
  • DANGER_GITLAB_API_BASE_URL: 'https://git.neds.sh/api/v4'
  • DANGER_GITLAB_API_TOKEN: <found in our Settings -> CI/CD -> Variables page>

Once you have those three environment variables available to your terminal, you will need to run npx danger pr and pass is a URL to a current MR in Gitlab, e.g. danger pr https://git.neds.sh/technology/code/ui/react-native/-/merge_requests/209

This will run Danger against the MR, evaluating all of the rules inside of dangerfile.ts in your local branch, and print out any messages, warnings and/or fails in the terminal, without actually posting a comment on that MR, allowing you to check any changes you're making to the rules before committing the changes to the main branch and changing what rules are checked by Danger in the CI pipelines.