Using Danger Process

#Danger Process

In version 2.0.0 and above, Danger comes with a new command: danger process. This command should have all the same parameters as danger and is meant to be an optional replacement. It’s idea is that the responsibilities of Danger can be split into three steps:

  • Dangerfile DSL setup.
  • Evaluation of a Dangerfile.
  • Handling the results of the Dangerfile run.

Danger JS will handle the first and the last steps, and another process will handle the second. This means most of the really tricky work stays inside Danger, and the other process can only has to worry about translating the DSL into something that feels natural in the environment of your app.

#Implementing a Danger Process Runner

danger process expects one argument, the command to trigger the process for Danger JS to run. This command should expect the Danger DSL as JSON in STDIN, and it is expected that it would post results to STDOUT via JSON.

You can preview the JSON using our Peril Staging environment, here are a few PRs:

Note: This DSL response does not include the GitHub API metadata, I plan to add this.

You can change the PR params to an public repo’s params to get a sense of what it looks like on your own PRs.

A runner can output anything during the process to STDOUT, and it will be logged to the user. However, Danger JS is listening for a JSON response in this format:

  "warnings": [{ message: "There isn't a CHANGELOG entry." }], 
  "fails": [], 
  "markdowns": [] 

Note: "markdowns" is a string array, everything else is an object with message. When Danger supports inline messages, then "file" and "line" will also be supported in the violation.

#Some Examples

The simplest example I can give you, ironically, is a runner using Ruby.

  #!/usr/bin/env ruby

require 'json'
dsl_json = STDIN.tty? ? 'Cannot read from STDIN' : $
danger = JSON.parse(dsl_json)
results = { warnings: [], messages:[], fails: [], markdowns: [] }

if "Hello world"
  results.messages << { message: "Hey there" }

require 'json'

As Ruby is duck-typed, it doesn’t need any infrastructure. You can parse the incoming JSON into an object, then work with the standard library to provide a Dangerfile environment. If you saved this file as dangerfile.rb, and chmod +x dangerfile.rb then you can run danger process 'dangerfile.rb.

Let’s look at something a bit more complex. Danger Swift.

Danger Swift aims to act more like a peer to Danger JS/Ruby, and so it is a two step process. The first process’ job is to evaluate a user’s Dangerfile instead of the rule evaluation happening inside the initial process.

Which means the code a user of Danger Swift only has to handle the DSL, and not the message receiving/sending to Danger JS.

To annoated this, Danger Swift takes a JSON document via STDIN, compiles and evaluates a Swift file and then passes the results back to danger process via STDOUT.

#Things You Probably Have To Do

At least to make it shine:

  • Implement a few of the functions inside the Danger DSL (sentence, fileLink in particular are useful)
  • Implement a GitHub API, today you can use ENV["DANGER_GITHUB_TOKEN"] to get the user’s access token

That’s probably it. You will need to provide instructions for someone with no node experience to set up Danger JS. On a Mac, that looks like:

brew install node
npm install -g danger

It’s pretty likely that your CI already has node, so it can just be npm install -g danger.

Got improvements? Help improve this document via sending PRs.