Bundler is a dependency manager for Ruby which uses a Gemfile to define all of the Ruby projects you want to use. To get started type in bundler init in your project folder.
This creates your Gemfile. Open this up in your editor, then replace the #gem 'rails' with the gem above. Then run bundle install inside your project folder.
This is optional. Pragmatically, you want to do this though.
- GitHub
- GitLab
- Bitbucket Server
- Bitbucket Cloud
In order to get the most out of Danger, we recommend giving her 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 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 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
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
To get the most out of Danger, we recommend giving her the ability to post comments in your Pull Requests. This is a regular Bitbucket Cloud account, that exists just for Danger.
Setting up the Environment Variables
To get set up, you will need to provide DANGER_BITBUCKETCLOUD_USERNAME, DANGER_BITBUCKETCLOUD_PASSWORD and your DANGER_BITBUCKETCLOUD_UUID into the CI environment.
To get the most out of Danger, we recommend giving her the ability to post comments in your Pull Requests. This is a regular Bitbucket account, that exists just for Danger.
Setting up the Environment Variables
To get set up, you will need to provide DANGER_BITBUCKETSERVER_USERNAME, DANGER_BITBUCKETSERVER_PASSWORD and your DANGER_BITBUCKETSERVER_HOST into the environment.
You will also want to ensure that ghprbPullId is added into the environment with the Pull Request
id so that Danger can use your Bitbucket Server’s API. As of right now, only Jenkins is supported for Bitbucket Server, we’re open to improvements there, for sure.
With your ENV vars set up, you can edit your job to add bundle exec danger at the build action.
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.
- Buddybuild
- Drone
- CodeBuild
- VSTS
- Bitrise
- AppVeyor
- Surf
- DotCi
- Appcenter
- TeamCity
- CircleCI
- Jenkins
- GitLabCI
- Semaphore
- LocalOnlyGitRepo
- GitHubActions
- XcodeServer
- BitbucketPipelines
- Codeship
- Buildkite
- Travis
- Screwdriver
CI Setup
Read how you can setup Danger on the buddybuild blog:
https://www.buddybuild.com/blog/using-danger-with-buddybuild/
Token Setup
Login to buddybuild and select your app. Go to your App Settings and
in the Build Settings menu on the left, choose Environment Variables.
http://docs.buddybuild.com/docs/environment-variables
GitHub
Add the DANGER_GITHUB_API_TOKEN to your build user's ENV.
GitLab
Add the DANGER_GITLAB_API_TOKEN to your build user's ENV.
Bitbucket Cloud
Add the DANGER_BITBUCKETSERVER_USERNAME, DANGER_BITBUCKETSERVER_PASSWORD
to your build user's ENV.
Bitbucket server
Add the DANGER_BITBUCKETSERVER_USERNAME, DANGER_BITBUCKETSERVER_PASSWORD
and DANGER_BITBUCKETSERVER_HOST to your build user's ENV.
Running Danger
Once the environment variables are all available, create a custom build step
to run Danger as part of your build process:
http://docs.buddybuild.com/docs/custom-prebuild-and-postbuild-steps
CI Setup
With Drone you run the docker images yourself, so you will want to add bundle exec danger at the end of
your .drone.yml.
build:
image: golang
commands:
- ...
- bundle exec danger
Token Setup
As this is self-hosted, you will need to expose the DANGER_GITHUB_API_TOKEN as a secret to your
builds:
Drone secrets: http://readme.drone.io/usage/secret-guide/
NOTE: This is a new syntax in DroneCI 0.6+
build:
image: golang
secrets:
- DANGER_GITHUB_API_TOKEN
commands:
- ...
- bundle exec danger
CI Setup
In CodeBuild, make sure to correctly forward CODEBUILD_BUILD_ID, CODEBUILD_SOURCE_VERSION, CODEBUILD_SOURCE_REPO_URL and DANGER_GITHUB_API_TOKEN.
Token Setup
Add your DANGER_GITHUB_API_TOKEN to your project. Edit -> Environment -> Additional configuration -> Create a parameter
CI Setup
You need to go to your project's build definiton. Then add a "Command Line" Task with the "Tool" field set to "bundle"
and the "Arguments" field set to "exec danger".
Token Setup
GitHub
You need to add the DANGER_GITHUB_API_TOKEN environment variable, to do this, go to your build definition's variables tab.
Make sure that DANGER_GITHUB_API_TOKEN is not set to secret since vsts does not expose secret variables while building.
VSTS
You need to add the DANGER_VSTS_API_TOKEN and DANGER_VSTS_HOST environment variable, to do this,
go to your build definition's variables tab. The DANGER_VSTS_API_TOKEN is your vsts personal access token.
Instructions for creating a personal access token can be found here.
For the DANGER_VSTS_HOST variable the suggested value is $(System.TeamFoundationCollectionUri)$(System.TeamProject)
which will automatically get your vsts domain and your project name needed for the vsts api.
Make sure that DANGER_VSTS_API_TOKEN is not set to secret since vsts does not expose secret variables while building.
CI Setup
Add a script step to your workflow:
- script@1.1.2:
inputs:
- content: |-
bundle install
bundle exec danger
Token Setup
Add the DANGER_GITHUB_API_TOKEN to your workflow's Secret App Env Vars.
CI Setup
Install dependencies and add a danger step to your appveyor.yml.
```yaml
install:
- cmd: >-
set PATH=C:\Ruby25-x64\bin;%PATH%
bundle install
after_test:
- cmd: >-
bundle exec danger
```
Token Setup
For public repositories, add your plain token to environment variables in appveyor.yml.
Encrypted environment variables will not be decrypted on PR builds.
see here: https://www.appveyor.com/docs/build-configuration/#secure-variables
yaml
environment:
DANGER_GITHUB_API_TOKEN: <YOUR_TOKEN_HERE>
For private repositories, enter your token in Settings>Environment>Environment variables>Add variable and turn on variable encryption.
You will see encrypted variable text in Settings>Export YAML so just copy to your appveyor.yml.
yaml
environment:
DANGER_GITHUB_API_TOKEN:
secure: <YOUR_ENCRYPTED_TOKEN_HERE>
CI Setup
You want to add bundle exec danger to your build.sh file to run Danger at the
end of your build.
Token Setup
As this is self-hosted, you will need to add the DANGER_GITHUB_API_TOKEN to your build user's ENV. The alternative
is to pass in the token as a prefix to the command DANGER_GITHUB_API_TOKEN="123" bundle exec danger.
CI Setup
DotCi is a layer on top of jenkins. So, if you're using DotCi, you're hosting your own environment.
Token Setup
GitHub
As you own the machine, it's up to you to add the environment variable for the DANGER_GITHUB_API_TOKEN.
CI Setup
Add a script step to your appcenter-post-build.sh:
#!/usr/bin/env bash
bundle install
bundle exec danger
Token Setup
Add the DANGER_GITHUB_API_TOKEN to your environment variables.
CI Setup
You need to go to your project settings. Then depending on the type of your build settings, you may need
to add a new build step for Danger. You want to be able to run the command bundle exec danger, so
the "Simple Command Runner" should be all you need to do that.
Token + Environment Setup
GitHub
As this is self-hosted, you will need to add the DANGER_GITHUB_API_TOKEN to your build user's ENV. The alternative
is to pass in the token as a prefix to the command DANGER_GITHUB_API_TOKEN="123" bundle exec danger.
However, you will need to find a way to add the environment vars: GITHUB_REPO_SLUG, GITHUB_PULL_REQUEST_ID and
GITHUB_REPO_URL. These are not added by default. You can manually add GITHUB_REPO_SLUG and GITHUB_REPO_URL
as build parameters or by exporting them inside your Simple Command Runner.
As for GITHUB_PULL_REQUEST_ID, TeamCity provides the %teamcity.build.branch% variable which is in the format
PR_NUMBER/merge. You can slice the Pull Request ID out by doing the following:
branch="%teamcity.build.branch%"
export GITHUB_PULL_REQUEST_ID=(${branch//\// })
GitLab
As this is self-hosted, you will need to add the DANGER_GITLAB_API_TOKEN to your build user's ENV. The alternative
is to pass in the token as a prefix to the command DANGER_GITLAB_API_TOKEN="123" bundle exec danger.
However, you will need to find a way to add the environment vars: GITLAB_REPO_SLUG, GITLAB_PULL_REQUEST_ID and
GITLAB_REPO_URL. These are not added by default. You could do this via the GitLab API potentially.
We would love some advice on improving this setup.
BitBucket Cloud
You will need to add the following environment variables as build parameters or by exporting them inside your
Simple Command Runner.
- DANGER_BITBUCKETCLOUD_USERNAME
- DANGER_BITBUCKETCLOUD_PASSWORD
- BITBUCKET_REPO_SLUG
- BITBUCKET_REPO_URL
You will also need to set the BITBUCKET_BRANCH_NAME environment variable.
TeamCity provides %teamcity.build.branch%, which you can use at the top of your Simple Command Runner:
sh
export BITBUCKET_BRANCH_NAME="%teamcity.build.branch%"
BitBucket Server
You will need to add the following environment variables as build parameters or by exporting them inside your
Simple Command Runner.
- DANGER_BITBUCKETSERVER_USERNAME
- DANGER_BITBUCKETSERVER_PASSWORD
- DANGER_BITBUCKETSERVER_HOST
- BITBUCKETSERVER_REPO_SLUG
- BITBUCKETSERVER_PULL_REQUEST_ID
- BITBUCKETSERVER_REPO_URL
CI Setup
For setting up CircleCI, we recommend turning on "Only build pull requests" in "Advanced Settings." Without this enabled,
it's trickier for Danger to determine whether you're in a pull request or not, as the environment metadata
isn't as reliable.
A common scenario is when CircleCI begins building a commit before the commit becomes associated with a PR
(e.g. a developer pushes their branch to the remote repo for the first time. CircleCI spins up and begins building.
Moments later the developer creates a PR on GitHub. Since the build process started before the PR existed,
Danger won't be able to use the Circle-provided environment variables to retrieve PR metadata.)
With "Only build pull requests" enabled, you can add bundle exec danger to your config.yml (Circle 2.0).
e.g.
- run: bundle exec danger --verbose
And that should be it!
Token Setup
If "Only build pull requests" can't be enabled for your project, Danger can still work by relying on CircleCI's API
to retrieve PR metadata, which will require an API token.
- Go to your project > Settings > API Permissions. Create a token with scope "view-builds" and a label like "DANGER_CIRCLE_CI_API_TOKEN".
- Settings > Environement Variables. Add the token as a CircleCI environment variable, which exposes it to the Danger process.
There is no difference here for OSS vs Closed, both scenarios will need this environment variable.
With these pieces in place, Danger should be able to work as expected.
CI Setup
Ah Jenkins, so many memories. So, if you're using Jenkins, you're hosting your own environment.
GitHub
You will want to be using the GitHub pull request builder plugin
in order to ensure that you have the build environment set up for PR integration.
With that set up, you can edit your job to add bundle exec danger at the build action.
Pipeline
If your're using pipelines you should be using the GitHub branch source plugin
for easy setup and handling of PRs.
After you've set up the plugin, add a sh 'bundle exec danger' line in your pipeline script and make sure that build PRs is enabled.
GitLab
You will want to be using the GitLab Plugin
in order to ensure that you have the build environment set up for MR integration.
With that set up, you can edit your job to add bundle exec danger at the build action.
General
People occasionally see issues with Danger not classing your CI runs as a PR, to give you visibilty
the Jenkins side of Danger expects to see one of these env vars:
- ghprbPullId
- CHANGE_ID
- gitlabMergeRequestIid
- gitlabMergeRequestId
Token Setup
GitHub
As you own the machine, it's up to you to add the environment variable for the DANGER_GITHUB_API_TOKEN.
GitLab
As you own the machine, it's up to you to add the environment variable for the DANGER_GITLAB_API_TOKEN.
CI Setup
Install dependencies and add a danger step to your .gitlab-ci.yml:
yml
before_script:
- bundle install
danger:
script:
- bundle exec danger
Token Setup
Add the DANGER_GITLAB_API_TOKEN to your pipeline env variables.
CI Setup
For Semaphore you will want to go to the settings page of the project. Inside "Build Settings"
you should add bundle exec danger to the Setup thread. Note that Semaphore only provides
the build environment variables necessary for Danger on PRs across forks.
Token Setup
You can add your DANGER_GITHUB_API_TOKEN inside the "Environment Variables" section in the settings.
CI Setup
For setting up LocalOnlyGitRepo there is not much needed. Either --base and --head need to be specified or
origin/master is expected for base and HEAD for head
CI Setup
You can use danger/danger Action in your .github/main.workflow.
action "Danger" {
uses = "danger/danger"
}
Token Setup
Set DANGER_GITHUB_API_TOKEN to secrets, or you can also use GITHUB_TOKEN.
action "Danger" {
uses = "danger/danger"
secrets = ["GITHUB_TOKEN"]
}
CI Setup
If you're bold enough to use Xcode Bots. You will need to use Buildasaur
in order to work with Danger. This will set up your build environment for you, as the name of the bot contains all
of the environment variables that Danger needs to work.
With Buildasaur set up, you can edit your job to add bundle exec danger as a post-action build script.
Token Setup
As this is self-hosted, you will need to add the DANGER_GITHUB_API_TOKEN to your build user's ENV. The alternative
is to pass in the token as a prefix to the command DANGER_GITHUB_API_TOKEN="123" bundle exec danger.`.
CI Setup
Install dependencies and add a danger step to your bitbucket-pipelines.yml.
yaml
script:
- bundle exec danger --verbose
Token Setup
Add DANGER_BITBUCKETCLOUD_USERNAME and DANGER_BITBUCKETCLOUD_USERNAME to your pipeline repository variable.
Settings > Pipelines > Repository Variables
CI Setup
In Codeship, go to your "Project Settings", then add bundle exec danger as a test step inside
one of your pipelines.
Token Setup
Add your DANGER_GITHUB_API_TOKEN to "Environment" section in "Project Settings".
CI Setup
With BuildKite you run the server yourself, so you will want to run it as a part of your build process.
It is common to have build steps, so we would recommend adding this to your scrip:
echo "--- Running Danger"
bundle exec danger
Token Setup
GitHub
As this is self-hosted, you will need to add the DANGER_GITHUB_API_TOKEN to your build user's ENV. The alternative
is to pass in the token as a prefix to the command DANGER_GITHUB_API_TOKEN="123" bundle exec danger.
GitLab
As this is self-hosted, you will need to add the DANGER_GITLAB_API_TOKEN to your build user's ENV. The alternative
is to pass in the token as a prefix to the command DANGER_GITLAB_API_TOKEN="123" bundle exec danger.
CI Setup
You need to edit your .travis.yml to include bundle exec danger. If you already have
a script: section then we recommend adding this command at the end of the script step: - bundle exec danger.
Otherwise, add a before_script step to the root of the .travis.yml with bundle exec danger
before_script:
- bundle exec danger
Adding this to your .travis.yml allows Danger to fail your build, both on the TravisCI website and within your Pull Request.
With that set up, you can edit your job to add bundle exec danger at the build action.
Note: Travis CI defaults to using an older version of Ruby, so you may need to add rvm: 2.0.0 to the root your .travis.yml.
Token Setup
You need to add the DANGER_GITHUB_API_TOKEN environment variable, to do this,
go to your repo's settings, which should look like: https://travis-ci.org/[user]/[repo]/settings.
If you have an open source project, you should ensure "Display value in build log" enabled, so that PRs from forks work.
CI Setup
Install dependencies and add a danger step to your screwdriver.yaml:
yml
jobs:
danger:
requires: [~pr, ~commit]
steps:
- setup: bundle install --path vendor
- danger: bundle exec danger
secrets:
- DANGER_GITHUB_API_TOKEN
Token Setup
Add the DANGER_GITHUB_API_TOKEN to your pipeline env as a
build secret
