How is Danger Swift architected

#How does Danger Swift work?

Danger provides an evaluation system for creating per-application rules. Basically, it is running arbitrary Swift with some extra PR metadata added in at runtime.

Pulling this off though, is a bit of a thing.

#Setup

Danger Swift is powered by Danger JS. Think of it as a Swift sandwich: [Danger JS] -> [Danger Swift] -> [Danger JS]. Danger JS first gets all the CI and Platform metadata, then passes that to Danger Swift, which returns the results of your Swift rules back to Danger JS.

+--------------------------------+          +----------------------+          +--------------------+
|                                |          |                      |          |                    |
| ## Danger JS                   |          | ## Danger Swift      |          | ## Danger JS       |
|                                |          |                      |          |                    |
|  Get GitHub/BitBucket/etc info |  +---->  |  Setup plugins       |  +---->  |  Update PR info    |
|                                |          |                      |          |                    |
|  Transform into JSON           |          |  Evaluate Dangerfile |          |  Pass / fail build |
|                                |          |                      |          |                    |
+--------------------------------+          +----------------------+          +--------------------+

Step 1: CI. Danger JS needs to figure out what CI we’re running on. You can see them all in source/ci_source/providers. These use ENV VARs to figure out which CI danger ci is running on and validate whether it is a pull request.

Step 2: Platform. Next, Danger JS needs to know which platform the code review is happening in. Today it’s just GitHub and BitBucket Server, but maybe GitLab is around the corner.

Step 3: JSON DSL. All the metadata from the above two steps are transformed into a JSON file, which is passed into Danger Swift.

Step 4: Swift Plugin Setup. Danger has to prepare your code to be compiled, so any plugins need to be set up before compilation and runtime evaluation.

Step 5: Evaluation. Most of the Danger Swift setup occurs when you run, let danger = Danger() in your Dangerfile.swift - it’s nearly all smart JSON parsing into real Swift-y objects. The dangerfile uses markdown, warning, fail or message to pass results to a singleton.

Step 6: Passing Results. The results from the evaluation are turned into JSON, and then passed back to Danger JS.

Step 6: Feedback. Danger JS reads the results, then chooses whether to create/delete/edit any messages in the code review site. From the results of the run, Danger JS will then pass or fail the build.


Got improvements? Help improve this document via sending PRs.