Get Started with Danger
So, you’re ready to get set up?
There are 5 steps involved in getting Danger running:
- Installing Danger Locally.
- Creating a Dangerfile and add a few simple rules.
- Creating an account for Danger to use.
- Setting up an access token for Danger with that account.
- Setting up Danger to run on your CI.
We recommend you install Danger via Swift Package Manager. Though you can use homebrew also. Using Swift PM means you safely lock your versions, making your tooling more reliable.
You’ll need to be using Xcode 10 or above. We need to create a package definition, so create a
in the root of your folder:
// swift-tools-version:4.2 import PackageDescription let package = Package( name: "Eigen", dependencies: [ .package(url: "https://github.com/danger/swift.git", from: "1.0.0") ], targets: [ // This is just an arbitrary Swift file in our app, that has // no dependencies outside of Foundation, the dependencies section // ensures that the library for Danger gets build also. .target(name: "eigen", dependencies: ["Danger"], path: "Artsy", sources: ["Stringify.swift"]), ] )
This is working around the system a little bit here, we create a SwiftPM build target that requires Danger (to ensure it gets compiled correctly) by adding Danger as a dependency. Next we create a build target that references a random Swift file in your app. This is so that libDanger will be created and because you have to have at least one build target in a Swift Package. Two birds, one bath.
You’ll have to find a file like this in your codebase, something that just imports
Foundation is enough.
swift build to verify your setup.
From this point on you can use
swift run danger-swift [cmd] to run Danger locked correctly to your project.
This is good for quick experiments, and is macOS only. Install homebrew, then run
brew install danger/tap/danger-swift.
Now you have a globally installed version of danger that’s available via
danger-swift [cmd] on your computer.
This won’t be version locked, so you’ll always be using the latest version of Danger Swift (and Danger JS) which is kinda risky. We’re good with testing builds etc, but SemVer breaks in either project will probably occur and you won’t have a choice but to migrate at the same time or face failing builds.
#Creating a Dangerfile
[swift run] danger edit - this will create a default
Dangerfile.swift and open an Xcode project
To get yourself started, add this to the
Dangerfile.swift in the Xcode project:
let editedFiles = danger.git.modifiedFiles + danger.git.createdFiles message("These files have changed: \(editedFiles.joined(separator: ", "))")
It will output the list of modified files for a PR, which we’ll test next. For a deeper understanding of how to write a Dangerfile, see the guide The Dangerfile.
Let’s try to run your new
Dangerfile.swift against an existing PR. If you’re interested in why, see this doc.
You can now test your current Dangerfile against an existing PR by running:
[swift run] danger-swift pr [url_of_pr]. It will only
leave messages in your terminal, not on the PR. This will run un-authenticated so it won’t work with private repos,
if you need a public PR to test, try:
[swift run] danger-swift pr https://github.com/danger/swift/pull/146.
#Creating a bot account for Danger to use
This is optional. Pragmatically, you want to do this though.
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.
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
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.
You can work with GitHub Enterprise by setting 2 environment variables:
DANGER_GITHUB_HOSTto the host that GitHub is running on.
DANGER_GITHUB_API_BASE_URLto the host that the GitHub Enterprise API is reachable on.
To use Danger Swift 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.
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 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
You should be able to verify that you have successfully integrated Danger by either re-building your CI or pushing your new commits.
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 Danger + iOS App. 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.
Got improvements? Help improve this document via sending PRs.