Lint, format, or static-analysis gate failure

What this failure means

A non-compiler quality gate failed during CI. The job stopped because lint, formatting, or static-analysis checks reported violations even though the code may still compile.

Symptoms

Faultline looks for one or more of these log fragments:

lint failed
format check failed
static analysis failed
quality gate failed
style violations found
code quality checks failed
formatting violations
checks did not pass

Diagnosis

A non-compiler quality gate failed during CI. This playbook is the generic fallback for quality tooling when Faultline cannot match a stronger tool-specific rule.

Fix steps

1. Re-run the exact quality-check command locally to see which files and rules are failing:

   make lint        # or: eslint ., golangci-lint run, ruff check .
   make check       # or a direct invocation of the tool
   

2. Fix the reported violations before considering any relaxation of the gate. Suppression comments (// nolint, # noqa) should be used sparingly and must include a justification.

3. If the failure followed a shared config update (.eslintrc, .golangci.yml, pyproject.toml), review that change and confirm the stricter rule was intentional before fixing callers.

4. If multiple tools run under one quality step, isolate each tool locally to identify whether the failure is lint, format, type-check, or another static-analysis check:

   eslint .                  # JavaScript linting only
   prettier --check .        # formatting only
   tsc --noEmit              # type-check only
   

Validation

• make lint and make check both exit 0.
• Re-run CI and confirm the quality gate passes.

Why it matters

Generic quality gates fail when contributor machines and CI enforce different formatting or analysis rules, when a shared ruleset changes, or when the codebase accumulates style or maintainability issues that CI treats as hard failures.

Prevention

• Keep formatter, lint, and static-analysis tool versions pinned so CI behavior changes only in deliberate upgrades.
• Run the same quality checks in pre-commit, pre-push, or editor integrations for changed files.
• Treat shared rule changes like product changes and roll them out with examples and remediation guidance.

Try it locally

make lint
make check
make lint
make check

How Faultline detects it

Use faultline explain quality-gate-failure to see the full playbook.

faultline analyze build.log
faultline explain quality-gate-failure

Generated from playbooks/bundled/log/build/quality-gate-failure.yaml. Do not edit directly.