Frequently Asked Questions

#Danger Swift takes a real long time to run

First off, make sure you have build caching turned on for:

  • ./build - for Swift PM, and compilation
  • ~/.danger-swift - for Danger Swift’s Dangerfile and dependency compilation

Danger Swift has to compile code etc, which you want to be doing incrementally.

Second, getting and using plugins does more work than you’d think. There is one key reason:

  • As of Swift 4.2, including any dependency will clone every related dependency. Think of it as “I include Danger in my dependency tree, and suddenly I have to clone ~12 repos (~6 unrelated to danger) on every build.”

This is currently the Swift PM dependency resolver being naive, and should get fixed in the future, build caching will work around it. We’ve got some code in Danger to try speed that up though.

#What’s with the weird Swift PM stuff?

Well, if SPM is the future of native build tools - we should be using it. It’s just that Danger’s use-case isn’t quite supported yet. Here’s some reasoning:

  • swift run relies on swift build which has to have a build target. If you want to just use external tools via SPM, then you’ll need to have a fake target.

  • danger-swift relies on libDanger existing in your build folders (or somewhere known for homebrew etc). This means that you will have to compile your build target before running swift run danger-swift.

  • You can’t have a build target that has no source files, so you’ll need to reference a single file.

These do add up to being a bit of a weird experience, but I’ve spec’d out what a Danger Swift v2 could look like to work around some of these oddities in danger/swift#139.

#Can I use the same Dangerfile across many repos?

Nope, but if this is something you care about Danger/Peril could support Swift Dangerfiles. I’m unlikely to write this support myself, but someone else could add it.

#I only want to run Danger for internal contributors

Let’s say you run Danger on the same CI service that deploys your code. If that’s open source, you don’t want to be letting anyone pull out your private env vars. The work around for this is to not simply call Danger on every test run:

'[ ! -z $DANGER_GITHUB_API_TOKEN ] && swift run danger-swift ci || echo "Skipping Danger for External Contributor"'

Or the same for BitBucket. This ensures that Danger only runs when you have the environment variables set up to run. This is how Danger works for a lot of the open source mobile projects in Artsy.

#Danger is not posting to GitHub PRs, but everything looks fine?

Try logging in to the GitHub account that should be writing the messages, it’s possible that your account has triggered the bot detection algorithm. This means that messages are sent correctly, but do not show up for anyone except the sender. This makes it more or less impossible to detect from Danger’s side.

#I’m not sure what Danger is doing

If you run danger with DEBUG="*" prefixed, you’ll get a lot of information about what’s happening under the hood. E.g:

DEBUG="*" [swift run] danger-swift pr https://github.com/danger/swift/pull/95

or on the CI:

DEBUG="*" [swift run] danger-swift ci

This will print out a lot of information.

#Circle CI doesn’t run my build consistently

Yeah… We’re struggling with that one. It’s something we keep taking stabs at improving, so keep an eye on the issues. Ideally this issue will get resolved and we’ll get it fixed for free.

What happens is that Circle triggers a CI build before the PR has been set up, and so Danger cannot get information about the corresponding repo and PR. Danger on Circle with use the Circle API to try and hook itself up to the right PR, so if you have yarn danger ci later on in the process, you’ll have a better chance of them hooking up.

This can be worked around by sending PRs from forks.

#I want to help influence Danger’s direction

We’d recommend first becoming acquainted with the VISION.md inside Danger, this is the long-term plan. Then there are two ways to start contributing today:

We keep comments in the public domain, there is a Slack, but it’s very rarely used. If you’re interested in joining, you can DM orta.

Got improvements? Help improve this document via sending PRs.