Automation 🤖

Hero image for Automation 🤖

Automatic code review using linters and code checkers (security, code smells) in Continuous Integration (CI) pipelines will give the team the chance to automate common code review chores. Automating chore tasks allows developers to think about harder problems by reducing the amount of manual work. Danger is a suitable tool for this because of its range of features and compatibility with all of Nimble’s platforms.

Danger and its plugins are the tools selected to include in the CI process to support automated code reviews.

In terms of implementation, we recommend checking our templates for more details.


Danger runs during the CI process, automating the team’s code conventions surrounding code review.

Danger provides another logical step in your process. Through this, Danger can automate the repetitive tasks in daily code review.

Danger in code review process

Moreover, Danger settings can be customized to match the team’s code conventions. Danger will create automatically review comments in pull requests based on the team’s defined rules.

An example in a pull request: Danger comment in a pull request example

Danger plugins

Danger was built to be a small core, allowing others to extend via gems as plugins.


For iOS projects, the team uses the following plugins to automate the code review process.


SwiftFormat is a code library and command-line tool for reformatting Swift code.

The Danger plugin of SwiftFormat is used to check the code style of the pull request code based on the rules defined from the SwiftFormat’s configuration.


SwiftLint is a tool to enforce Swift style and conventions, loosely based on the now archived GitHub Swift Style Guide. SwiftLint enforces the style guide rules that are generally accepted by the Swift community. These rules are well described in popular style guides like Ray Wenderlich’s Swift Style Guide.

The SwiftLint plugin is a wrapper around SwiftLint to check the code style of the pull request code. By using inline_mode, the lint result shows in diff instead of a comment, which is more convenient for developers to find the problem.

Xcode Summary

The Xcode Summary plugin is used to show all build errors, warnings, and unit tests generated from xcodebuild in the pull request’s comment.


The Danger plugin of xcov is a friendly visualizer for Xcode’s code coverage files. It will show the current code coverage of the current branch, and the code coverage of each file changes in the pull request’s comment.


For Android projects, the team uses a set of plugins to automate the code review process as follows:

Commit Lint

The Commit Lint plugin is a Danger plugin that focuses on linting the Pull Request’s commit messages, making sure they are nice and tidy. The checks performed on each commit message are inspired by Tim Pope’s blog post on good commit messages, echoed by git’s own documentation on the subject. Hence this can be a good plugin which can be applied for other platforms like iOS or Web.


Detekt is a static code analysis tool for the Kotlin programming language.

The Kotlin Detekt Danger plugin is used to analyze code smell from files of a Gradle-based Android project. Furthermore, this plugin can generate complexity reports based on lines of code, cyclomatic complexity, and amount of code smells with support for inlining comments directly to the Pull Request.

Android Lint

The Android Lint tool is another static code analysis tool that checks the project source files for potential bugs and optimization improvements for correctness, security, performance, usability, accessibility, and internationalization.

The Danger plugin of Android Lint is used for linting files of a Gradle-based Android project with a load of different configurations for reporting and the Pull Request’s inline comments support.


The Shroud plugin is a Danger tool for enforcing and warning code coverage via a Jacoco coverage report. Therefore, for Android projects, it relies on the Jacoco Android Gradle to work. A standout aspect for this plugin to be chosen for handling coverage reporting is because it can show the full report with the coverage data for each class when integrated successfully with the CI pipelines.