Understanding Service-Lint Reports

Service-Lint reports every violation it finds, grouped by severity. Understanding the severity model tells you what you must fix versus what is advisory.

Severity Levels

Severity Meaning Fails build?

ERROR

A real problem that blocks a pull request (e.g. inconsistent POM versions, mismatched deployment image tags, disallowed base images).

Yes

WARNING

Should be addressed but does not block by default (e.g. missing CHANGELOG entry, out-of-date base image, CORS wildcard).

No (by default)

INFO

Advisory information (e.g. a newer version of service-lint or the Maven tiles is available).

No

Each rule declares its own severity. Browse All Rules to see the severity of every rule, grouped by level.

Exit Codes

Service-Lint sets its process exit code based on ERROR-level violations only:

  • 0 — Success: no ERROR-level violations.

  • 1 — Failure: one or more ERROR-level violations.

WARNING and INFO violations are printed but do not change the exit code. This is what lets CI gate on ERRORs while still surfacing softer feedback.

failOnViolation

The Maven plugin’s failOnViolation parameter (default true) controls whether ERROR violations fail the Maven build. Set it to false to run rules and print the report without breaking the build — useful during a phased rollout or when introducing new rules:

mvn service-lint:check -DfailOnViolation=false

Note this affects the Maven build result; the CLI still returns exit code 1 on ERRORs.

Reducing Noise

If a rule reports something that legitimately doesn’t apply, prefer the narrowest suppression:

Prefer fixing a violation over silencing it. Suppress only genuine false positives or accepted exceptions.

See Also