Deprecation Notice: This repo has been deprecated, since SwiftLint integration is now a part of Danger Swift as a first-class feature. You can read this issue for context. This repo will remain available for legacy use, but new projects should not use this repo.
(Note: If you're looking for the Ruby version of this Danger plugin, it has been moved here.)
Install and run Danger Swift as normal and install SwiftLint in your CI's config file. Something like:
dependencies: override: - npm install -g danger # This installs Danger - brew install danger/tap/danger-swift # This installs Danger-Swift - brew install swiftlint # This is for the Danger SwiftLint plugin.
Then use the following
// Dangerfile.swift import Danger import DangerSwiftLint // package: https://github.com/ashfurrow/danger-swiftlint.git SwiftLint.lint()
That will lint the created and modified files
If you want the lint result shows in diff instead of comment, you can use inline_mode option. Violations that out of the diff will show in danger's fail or warn section.
Config & Directory
You can also specify a path to the config file using
configFile parameter and a path to the directory you want to lint using
directory parameter. This is helpful when you want to have different config files for different directories. E.g. Harvey wants to lint test files differently than the source files, thus they have the following setup:
SwiftLint.lint(directory: "Sources", configFile: ".swiftlint.yml") SwiftLint.lint(directory: "Tests", configFile: "Tests/HarveyTests/.swiftlint.yml")
Lint all files
By default, only files that were added or modified are linted.
It's not possible to use nested configurations in that case, because Danger SwiftLint lints each file on it's own, and by doing that the nested configuration is disabled. If you want to learn more details about this, read the whole issue here.
However, you can use the
lintAllFiles option to lint all the files. In that case, Danger SwiftLint doesn't lint files individually, which makes nested configuration to work. It'd be the same as you were running
swiftlint on the root folder:
Custom SwiftLint binary path
By default, Danger SwiftLint runs
swiftlint assuming it's installed globally. However, there're cases where it makes sense to use a different path. One example would be if you've installed SwiftLint using CocoaPods.
To use another binary, you can use the
If you find a bug, please open an issue! Or a pull request
This is the first command line Swift I've ever written, and it's the first Danger Swift plugin anyone has ever written, so if something doesn't work, I could really use your help figuring out the problem.
A good place to start is writing a failing unit test. Then you can try to fix the bug. First, you'll need to fork the repo and clone your fork locally. Build it and run the unit tests.
git clone https://github.com/YOUR_USERNAME/danger-swiftlint.git cd danger-swiftlint swift build swift test
Alright, verify that everything so far works before going further. To write your tests and modify the plugin files, run
swift package generate-xcodeproj. Open the generated Xcode project and enjoy the modernities of code autocomplete and inline documentation. You can even run the unit tests from Xcode (sometimes results are inconsistent with running
One place that unit tests have a hard time covering is the integration with the
swiftlint command line tool. If you're changing code there, open a pull request (like this one) to test everything works.
There are tonnes of ways this plugin can be customized for individual use cases. After building the Ruby version of this plugin, I realized that it's really difficult to scale up a tool that works for everyone. So instead, I'm treating this project as a template, that you to do fork and customize however you like!
- Fork this project.
- Change the
import DangerSwiftLintpackage URL to point to your fork.
- After making your changes to the plugin, push them to your fork and push a new tag.
Because you need to tag a new version, testing your plugin can be tricky. I've built some basic unit tests, so you should be able to use test-driven development for most of your changes.
If you think you've got a real general-purpose feature that most users of this plugin would benefit from, I would be grateful for a pull request.