Skip to content

Severity and exit codes

Every rule carries a level, and every alint check returns an exit code. The level decides how loud a finding is; the exit code is what your CI gates on. The mapping is small and fixed.

Severity levels mapped to exit codes A rule's level maps to an exit code. error exits 1 and fails the run. warning exits 0 by default, or 1 with the --fail-on-warning flag. info exits 0 and is reported only. off means the rule is skipped. A bad config or usage exits 2; an internal error exits 3. a level maps to an exit code error exit 1fails the run warning exit 0or 1 with --fail-on-warning info exit 0reported only off skippedrule never runs exit 2 = bad config or usage exit 3 = internal error

The four levels

Section titled “The four levels”
  • error is a hard failure. Any error-level violation makes alint check exit non-zero, which is what fails a CI job or blocks a commit.
  • warning is reported but does not fail the run by default. Pass --fail-on-warning to promote warnings into failures when you want a stricter gate.
  • info is advisory. It shows in the report and never affects the exit code.
  • off disables the rule entirely: it is dropped at config load and never runs. Setting level: off on an inherited rule is how you switch off something a ruleset you extends: turned on.

The exit codes

Section titled “The exit codes”

alint check returns one of four codes, so a pipeline can tell “clean” from “found problems” from “misconfigured”:

  • 0 clean: no errors, and no warnings under --fail-on-warning.
  • 1 findings: at least one error, a warning while --fail-on-warning is set, or a stale baseline entry while --strict-baseline is set.
  • 2 a bad config or bad usage (an unknown field, a malformed .alint.yml, an invalid flag).
  • 3 an internal error (a bug). Distinct from 2 so CI can tell “your config is wrong” apart from “alint fell over.”

In practice

Section titled “In practice”

A CI step that blocks on errors is just alint check (a non-zero exit fails the job). To also block on warnings during a hardening push:

alint check --fail-on-warning

And to keep a rule in the config but stop it from firing, without deleting it:

rules:
  - id: legacy-header
    level: off      # inherited from a ruleset; silenced here

Going deeper

Section titled “Going deeper”
  • The config model covers where level sits in the rule record and how a child config overrides it.
  • How alint works shows where the report and its exit code are produced.