Skip to content
Latchkey

yamllint: Lint Workflow and Pipeline YAML

yamllint validates the raw YAML of workflow and pipeline files (indentation, duplicate keys, line length) so structural mistakes are caught before a schema-aware linter.

Schema linters like actionlint assume valid YAML. yamllint catches the layer below: a bad indent or a duplicated key that would make the schema linter's error confusing. This page focuses on the CI-config use; see the dedicated yamllint modules for full rule details.

What it does

yamllint parses YAML and applies configurable rules (indentation, trailing spaces, line-length, key-duplicates, truthy values). For CI config it is a fast first pass that fails on structural YAML errors an action schema check would otherwise hide.

Common usage

Terminal
yamllint .github/workflows/
yamllint -d relaxed .gitlab-ci.yml
yamllint -f github .github/workflows/ci.yml   # GitHub annotations
yamllint -s .woodpecker.yml                   # strict: warnings fail

Options

FlagWhat it does
-d <conf>Use a config: default, relaxed, or a path
-f <format>Output format: standard, github, parsable, colored
-s, --strictReturn nonzero on warnings as well as errors
-c <file>Path to a .yamllint config file

In CI

Run yamllint before actionlint or glab ci lint so a raw-YAML error is reported plainly first. Use -f github in GitHub Actions to get inline annotations. Relax the line-length rule for workflow files, which often have long run: commands.

Common errors in CI

Findings look like 12:81 error line too long (95 > 80 characters) (line-length) and 5:3 error duplication of key "steps" in mapping (key-duplicates) and syntax error: could not find expected ':' (syntax). A syntax error means yamllint could not even parse the file, so fix that before running a schema linter.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →