yamllint --strict: Fail on Warnings
yamllint --strict returns a non-zero exit code when warnings are present, not just errors, so style warnings fail the build.
By default yamllint warnings do not fail CI. The --strict flag and per-rule levels decide whether warnings gate the pipeline.
What it does
Each yamllint problem has a level: error or warning. Without --strict, only errors cause exit code 1; warnings print but exit 0. --strict makes warnings also exit non-zero. --no-warnings goes the other way and suppresses warning output entirely.
Common usage
# warnings now fail the job
yamllint --strict .
# only show and gate on errors
yamllint --no-warnings .
# combine with a config that sets per-rule levels
yamllint -c .yamllint --strict .github/workflows/Options
| Flag / behavior | Effect on exit code |
|---|---|
| (default) | Exit 1 only when an error-level problem exists |
| --strict | Exit 1 when any error or warning exists |
| --no-warnings | Hide warnings; exit on errors only |
| rules.<rule>.level: error | Promote a specific rule to fail without --strict |
In CI
For a strict gate, either pass --strict globally or set the rules you care about to level: error in .yamllint, which fails on just those without making every warning blocking. Pick one approach and keep it consistent so local and CI runs agree.
Common errors in CI
A job that passes despite visible "[warning]" lines is running without --strict; that is expected default behavior, not a bug. After adding --strict, previously tolerated warnings (line-length, comments spacing) start failing; fix them or adjust the rule level in the config.