Getting Started with Danger JS

So, you’re ready to get set up? You have two options, go through this tutorial or run yarn add danger --dev; yarn danger init inside your project file then come back for the CI integration once you’re done. Or just get started below.

There are 5 steps involved in getting Danger running:

#Including Danger

We recommend you install Danger via Yarn. Though you can use the npm CLI.

#Installation

Adding the Danger module by yarn add danger --dev. This will add Danger as a devDependency and make the command danger available by running yarn danger.

#Creating a Dangerfile

Create either a new file, either dangerfile.js or dangerfile.ts will be picked up automatically. Otherwise you can use an argument to pass in a custom file.

To get yourself started, try this as your Dangerfile:

import {message, danger} from "danger"

const modifiedMD = danger.git.modified_files.join("- ")
message("Changed Files in this PR: \n - " + modifiedMD)

It will output the list of modified files for your current PR once you have your authentication set up below.

For a deeper understanding of using a Dangerfile, see the guide The Dangerfile

#Creating a bot account for Danger to use

This is optional. Pragmatically, you want to do this though.

#GitHub

In order to get the most out of Danger, we recommend giving it the ability to post comments in your Pull Requests. This is a regular GitHub account, but depending on whether you are working on a private or public project, you will want to give different levels of access to this bot. You are allowed to have one bot per GitHub account.

To get started, open https://github.com in a private browser session.

#OSS Projects

Do not add the bot to your repo or to your organization.

#Closed Source Projects

Add the bot to your repo or to your organization. The bot requires permission level “Write” to be able to set a PR’s status. Note that you should not re-use this bot for OSS projects.

#Setting up an Access Token

Here’s the link, you should open this in the private session where you just created the new GitHub account. Again, the rights that you give to the token depend on the openness of your projects. You’ll want to save this token for later, when you add a DANGER_GITHUB_API_TOKEN to your CI.

#Tokens for OSS Projects

We recommend giving the token the smallest scope possible. This means just public_repo, this scope is still ideally too much but this account shouldn’t have any access to other repos or organizations - so malicious use of the token is scoped to making new repos on it, or writing comments on other OSS projects. Because the token can be quite easily be extracted from the CI environment, this minimizes the chance for bad actors to cause chaos with it.

#Tokens for Closed Source Projects

We recommend giving access to the whole repo scope, and its children.

#Enterprise GitHub

You can work with GitHub Enterprise by setting 2 environment variables:

  • DANGER_GITHUB_HOST to the host that GitHub is running on.
  • DANGER_GITHUB_API_BASE_URL or GITHUB_URL to the host that the GitHub Enterprise API is reachable on.

For example:

DANGER_GITHUB_HOST=git.corp.evilcorp.com
DANGER_GITHUB_API_BASE_URL=https://git.corp.evilcorp.com/api/v3

#GitLab

To get the most out of Danger, we recommend giving her the ability to post comments in your Merge Requests. This is a regular GitLab account, but depending on whether you are working on a private or public project, you will want to give different levels of access to this bot.

To get started, open https://gitlab.com (or your GitLab instance) in a private browser session.

#OSS Projects

Do not add the bot to your project or to your group.

#Closed Source Projects

Add the bot to your private project or to your private group with the “Reporter” permission level. Note that you should not re-use this bot for OSS projects. As the access token you use could be extracted and would give access to your closed source projects.

#Setting up an Access Token

Here’s the link, you should open this in the private session where you have just created the new GitLab account. You’ll want to copy the token for later, when you add a DANGER_GITLAB_API_TOKEN to your CI.

If you are self hosting GitLab, you’ll need to generate an access token for the bot user. You can find the section under “Access Tokens” in the bot user’s profile.

#Self-hosted GitLab

To let Danger know the API details around your custom setup, you need to set two env variables:

DANGER_GITLAB_HOST to the host that GitLab is running on.

DANGER_GITLAB_API_BASE_URL to the host that the GitLab API is reachable on.

For example:

DANGER_GITLAB_HOST=git.corp.evilcorp.com
DANGER_GITLAB_API_BASE_URL=https://git.corp.evilcorp.com/api/v4

#BitBucket Server

To use Danger JS with BitBucket Server, you’ll need to create a new account for Danger to use, then set the following environment variables on your CI:

  • DANGER_BITBUCKETSERVER_HOST = The root URL for your server, e.g. https://bitbucket.mycompany.com.
  • DANGER_BITBUCKETSERVER_USERNAME = The username for the account used to comment.
  • DANGER_BITBUCKETSERVER_PASSWORD = The password for the account used to comment.

This account is then used to provide feedback on your PRs.

#Continuous Integration

Continuous Integration is the process of regularly running tests and generating metrics for a project. It is where you can ensure that the code you are submitting for review is passing on all of the tests. You commonly see this as green or red dots next to commits.

Danger is built to run as a part of this process, so you will need to have this set up as a pre-requisite.

#Setting up Danger to run on your CI

#Verify Installation

You should be able to verify that you have successfully integrated Danger by either re-building your CI or pushing your new commits.

#What now?

There are a few of places you can go from here. We’d recommending opening tabs on all these articles:

Then depending on the type of project you are working on, checking out either Danger + Node App, or Danger + Node Library. These should give you good overview of what is possible from here, then it’s really up to you to find how you can codify some aspects of your team’s culture.

Good luck!


Got improvements? Help improve this document via sending PRs.