Skip to content

Using ansible-lint to Catch Mistakes


This course has taught a lot of best practices by hand — quote your mode values, use FQCN module names, prefer loop over with_items, recurse combine deliberately. ansible-lint automates checking for a genuinely large share of it, catching mistakes before a playbook ever actually runs.

Installing It

pip install ansible-lint

Running It

ansible-lint site.yaml
ansible-lint roles/myapp

Runs against a playbook or an entire role directory, reporting issues without executing anything at all.

An Example: Catching The mode-Quoting Gotcha

Recall the file module chapter’s warning about unquoted mode values:

- name: Create a directory
  ansible.builtin.file:
    path: /etc/myapp
    state: directory
    mode: 0755
site.yaml:5: yaml[octal-values]: Found a bare octal value — quote it as a string ('0755')

Exactly the mistake that chapter warned about, caught automatically, with a specific line number, before this playbook ever runs against a real host.

An Example: Catching A Missing FQCN

Recall the ad hoc chapter’s recommendation to use fully-qualified module names:

- name: Install curl
  package:
    name: curl
    state: present
site.yaml:2: fqcn[action-core]: Use the FQCN 'ansible.builtin.package' instead of 'package'

Best Practices

  • Run ansible-lint routinely, not just when something’s already gone wrong — treat it the way you’d treat any other automated check that catches mistakes cheaply, before they matter.
  • Add it to CI, so a lint failure blocks a merge the same way a genuine test failure would.
  • Treat its findings as reinforcement of practices this course already taught deliberately, not arbitrary rules — a large share of what it catches maps directly to specific gotchas covered throughout this entire course.
Last updated on