swiftlint: error: 23 violations found: PR review blocked

TL;DR

SwiftLint found 23 violations and the step treats any violation as failure. Run it locally, autocorrect what is safe, fix the rest by hand, and tune the ruleset so the gate enforces rules the team actually agreed on. The count drops to zero and the gate passes.

The error

swiftlint: error: 23 violations found: PR review blocked

Steps

1. Reproduce locally with the same strictness

From the repo root, run what CI runs:

swiftlint lint --strict

Expected output: the same 23 violations, with file names and line numbers.

2. Autocorrect the safe fixes

Many style violations have automatic fixes:

swiftlint --fix

Review the resulting diff before committing it. Expected output: the correctable violations disappear.

3. Fix the remaining violations by hand

Work through the list. Common ones are line length, force unwrapping, and naming. Fix the code rather than the linter where the rule has a point. Expected output: the violation count keeps dropping.

4. Tune the ruleset deliberately

Open .swiftlint.yml and disable or downgrade rules the team does not want enforced. A rule that everyone suppresses is a rule that should not be an error. Expected output: the config reflects the team's actual standards.

5. Verify a clean run

swiftlint lint --strict

Expected output: no violations, exit 0. Push and watch the gate pass.

When to use

• The exact violations-found gate failure
• A new SwiftLint version introduces new default rules
• Adopting SwiftLint on an existing codebase

When not to use

• SwiftLint crashing or hanging
• Config file failing to load
• Build failures unrelated to lint

Tool compatibility

• SwiftLint 0.54 and later
• Xcode 14 and later toolchains
• Swift Package Manager and Xcode projects

Variant phrasings

swiftlint violations failing CI

Same fix. Reproduce, fix, verify.

swiftlint too many violations on old code

Baseline the existing code: warn on legacy paths while gating new code strictly.

swiftlint autocorrect changed too much

Run the fix mode on a clean branch, review the diff, and commit it separately from feature work.

Why it happens

SwiftLint exits nonzero when violations remain at or above the configured severity threshold, and strict mode promotes warnings to failures. CI treats the nonzero exit as a failed gate. The violations are real findings against the active ruleset.

Edge cases

• The fix mode can reformat large sections. Review its diff like any other code change.
• Version skew between local and CI changes the rule set. Pin the SwiftLint version in CI.
• Xcode version differences can shift which rules fire. Keep the toolchain consistent.
• Disabling rules per file with comments is fine for genuine exceptions, but a file full of them signals the rule or the code needs rethinking.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHHROjVaFWjEUKFF9H_4bg