Ansible lint

Ansible-lint is a static analysis tool that reviews your Ansible playbooks, roles, and collections to surface errors, stylistic issues, and potentially dangerous constructs before they run. Think of it as an automated, consistent code reviewer that enforces best practices across your automation repository. You may already use Ansible’s --check (check mode) and --diff to preview changes without applying them — those help verify what changes would happen. Ansible-lint complements that by verifying how the playbooks are written, helping keep them readable, consistent, and maintainable as projects grow.

What ansible-lint does

Scans playbooks, roles, and collections for common mistakes and style inconsistencies.
Reports rule violations with file and line numbers, plus an identifying tag (e.g. name[casing]) so you know what to fix.
Can be run locally, in pre-commit hooks, or as part of CI pipelines to enforce standards automatically.

More: ansible-lint documentation

Example: find style issues quickly Consider a sample playbook style-example.yml that installs and configures NGINX but intentionally includes a few style problems:

Inconsistent indentation (some tasks use two spaces, one uses four).
Inconsistent or missing task name fields (mixed case and some unnamed tasks).
Using the shell module where command or a dedicated module would be safer and faster.

Run ansible-lint and it will list problems with file names and line numbers:

$ ansible-lint style-example.yml
style-example.yml:9: name[casing]: Names must start with an uppercase letter.
style-example.yml:10: yaml[indentation]: Wrong indentation: expected 6 but found 8
style-example.yml:14: name[missing]: All tasks should be named.

Each message ends with a rule tag (for example name[casing]), and the output points to the offending line. Common rules you’ll see include task naming rules, YAML indentation issues, and warnings about unnecessary shell usage — when shell features (like pipes or expansions) aren’t required, prefer command or a specialised module.

Quick note on exit codes

If ansible-lint prints nothing and exits with code 0, it found no issues:

$ ansible-lint style-example.yml
# (no output) — exit code 0 indicates no issues

Non-zero exit codes indicate one or more linting failures — useful for failing CI jobs or blocking merges when used in automation.

Common ansible-lint rules (examples)

Rule tag	What it checks	Example / Fix
`name[casing]`	Task names should follow casing conventions	Rename `- name: install package` → `- name: Install package`
`name[missing]`	Tasks should have descriptive names	Add `name:` to unnamed tasks
`yaml[indentation]`	Enforce consistent YAML indentation	Fix spacing to match playbook indentation level
`shell`	Avoid `shell` when `command` or modules suffice	Use `command: ls -l` or a dedicated module instead of `shell`

Integrating ansible-lint into your workflow

Run it locally during development to catch issues early.
Add it to pre-commit hooks so every commit is checked automatically.
Include it in CI pipelines so pull requests are validated before merging.

Integrate ansible-lint into pre-commit hooks or CI jobs so lint failures block merges until issues are resolved. This enforces consistent style and prevents regressions across the team.

Benefits

Prevents style and correctness regressions in large automation codebases.
Saves time by turning ad-hoc reviews into automated checks.
Improves maintainability and readability of playbooks, roles, and collections.

A clean slide titled "A Review on Every Change" showing four numbered steps: 01 Commit a Change, 02 CI Picks It Up, 03 Ansible-lint Reviews, and 04 Merge, each with a short explanatory line. The layout emphasizes an automated CI review workflow for code changes.

Links and references

Official docs: https://ansible-lint.readthedocs.io/
Ansible best practices: https://docs.ansible.com/
Pre-commit: https://pre-commit.com/

By making ansible-lint a routine part of development and CI, you get an automated, consistent “mentor” for your Ansible codebase — catching issues early and keeping automation reliable and maintainable as it scales.

Introduction

Configuration and Basic Concepts

Ansible Inventory

Ansible Variables and Facts

Ansible Playbooks

Ansible Modules & Plugins

Ansible Handlers, Roles and Collections

Ansible Templates

Appendix

Watch Video

Practice Lab