At VTS, we care a lot about code quality. We recently started using Danger to automate some of our processes during code review — including some of our (my) goofier processes, like posting a random gif to every pull request.

Most notably, we’ve setup SwiftLint in our CI environment through Danger, and set up a bot to post a comment with all warnings/errors for files touched in a pull request.

Integrating SwiftLint Into a Project

SwiftLint is a static analysis tool that can be used to setup rules to find style violations, breaks with convention, and some more serious issues (possible reference cycles, etc…). It can be set up to report within Xcode itself, leveraging Xcode’s warnings and errors to notify you of issues.

Setting it up is relatively easy — begin by creating a .swiftlint.yml file, and filling it up with some rules. As an example, here’s a slightly modified version of ours:

Once that file is created and placed in the top-level-directory of your project, we only have to do two more things:

Voila!

We should now be able to see SwiftLint run in our Xcode project.

But in order to make it really useful, we’re going to need this to run in the context of our continuous integration environment.

Enter: Danger

Danger

Danger is a tool created by Orta Therox and Juanito Fatas for automating tasks during code review. In order to get it going, make sure you gem install danger in the setup phase of your CI script, and that you call danger before you run your tests. You’re also going to need a Dangerfile in order to have your configuration, so let’s take a look at a modified version of ours to start:

This is a very basic configuration that should just let you know if a PR is a bit large and if it’s tagged as a work in progress. This will become much more useful once we integrate SwiftLint into it.

To integrate SwiftLint, let’s begin by going to our CI script and adding gem install danger-swiftlint to our setup. Next, let’s add this script to our scripts directory (or similar) and call it in our CI setup with ruby scripts/generate_ci_yaml.rb :

This script takes a copy of our SwiftLint configuration, strips our includes , and then spits out a copy of that file. The reason that we want to do this is so that we only lint the files that we’ve touched, instead of all of them.

In our Dangerfile, we’re going to append just two more lines:

At this point, we’re running Swiftlint in the context of danger, but the output is confined to our CI environment.

Danger is most effective if there’s an organization bot account for Danger to use. This allows your bot to post a comment to your PR, like so:

Immediate Results

Developers started fixing more SwiftLint issues — we have cleaner code now! We started splitting up large pull requests into smaller ones. We started integrating more rules into our Dangerfile — we’re currently setting up CodeCoverage comparison of lines/files you touched vs master through danger-xcov and linting our commit messages with regard to our engineering guidelines.

More Links: