## 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
```text
swiftlint: error: 23 violations found: PR review blocked
```

## Steps

### 1. Reproduce locally with the same strictness
From the repo root, run what CI runs:
```bash
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:
```bash
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
```bash
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/pst_HHROjVaFWjEUKFF9H__4bg