danger / Announcements

Announcing Danger 2.0

Announcing Danger 2.0

November 5, 2017 · 6:58pm
3 months ago I started working on Danger 2.0 in August The aim for 2.0 was to move away from Jest's VM infrastructure in order to simplify integration of Danger into projects that already use Jest, as well as to look into building security tools into Danger so that hosted-Danger (Peril could "safely" evaluate/sandbox arbitrary JavaScript from the internet.) .

It was a pretty small aim, but it would need to be a major version break because I couldnt be certain that the exact same Dangerfile setup would run once I brought a lot of that work into Danger. Danger got a lot of free work from Jest, but my favourite was that Danger got a config-less transpilation setup. Jest also provided a great API for running code inside a sandbox'd environment.

To get started, I first explored vm2 as an option for handling the sandbox, this worked, but had issues with modules that used Proxy, which Babel used in it's regenerator-runtime. This made it real tough to consider for 2.0 as the main way to evaluation JavaScript.

A few weeks after starting work on 2.0, I came to a startling conclusion based on some work I had been doing to improve documentation inside the editor on Danger.Systems (if you've not tried it, you should, it's really slick). Danger could be split in two*.

This is what became the key paradigm for what 2.0 represents. A move from Danger being one process to being two processes. Why though? Well, there's a single key reason: Separation of Danger setup + messaging from user-code evaluation.

This is great for everyone because it:

  • Removes the need to schedule any Promise inside Dangerfiles. This is because we're not running JavaScript inside a vm which cannot wait for all ticks to finish. Instead, it's a full instance of a node script whose job is to run the Dangerfile, Danger will wait for the process to terminate which indicates it's time to send the message back to the code-review platform., s

  • Any process can be a Dangerfile runner, so long as you can read from STDIN and post JSON to STDOUT. Here's a trivial Ruby script that acts like a Dangerfile:


#!/usr/bin/env ruby require 'json' dsljson = STDIN.tty? ? 'Cannot read from STDIN' : $stdin.read danger = JSON.parse(dsl json).danger results = { warnings: [], messages:[], fails: [], markdowns: [] } if danger.github.pr.body.include? "Hello world" results.messages << { message: "Hey there" } end require 'json' STDOUT.write(results.to_json)

Danger JS uses the exact same technique danger will call danger runner under the hood once the DSL is ready. This is meant that other languages can build their own runners, for example Swift and Go It's now a pretty small amount of work to build a new language integration on top of Danger JS. .


This also represents the time towards helping the community help each other, I've been running a private Danger slack for 2 years but it's not really a place to ask questions - it's for implementation questions. So, I've moved to using Spectrum for user support as of 2.0. I'm optimistic that it's indexed by google, and is oriented towards supporting large communities of OSS developers. So if you have questions, ask here :+1:

November 5, 2017 · 7:57pm
🎉🎉🎉
like-fill
0
reply

So the TL;DR is nothing should change for users, but the entire insides were ripped out to make hosted Danger easier to do?

like-fill
0
reply

Yep, a publicly available hosted Danger is now possible and I have done my feasibility testing: https://github.com/danger/peril/issues/159

like-fill
0
reply
Your message here...

*bold*_italic_`code````codeblock```