SwitchTenderSwitchTender Docs

Ansible runs

An Ansible run executes ansible-playbook against an inventory. It is the default tool. A run that names no tool is an Ansible run. It is also the most instrumented one, because the embedded callback plugin reports every task on every host as a structured event, and those events paint the live host-by-task matrix, feed fleet memory, and drive drift detection.

What runs

The playbook path is the run's target, resolved inside the project checkout when the run sources a project, so relative paths and roles behave the way they do in the repository. A project's requirements.yml roles and collections install on sync before the play starts. A dry run passes --check, which reports what would change without changing it; drift detection is built from exactly those check runs.

Ansible runs are the ones that split. A split run shards the inventory across parallel slices, packs hosts onto shards by their measured durations from past runs, and merges every slice back into one matrix. Failed shards retry alone, and relaunch-failed re-runs only the hosts a finished run left failed or unreachable.

A run or template may carry the usual Ansible controls without a hand-built command: tags and skip_tags select or exclude tagged plays and tasks, forks sets how many hosts run at once, verbosity from one to four raises logging as -v through -vvvv, and diff_mode shows the before and after of every changed file. They are Ansible-only and the other tools ignore them.

How values reach the play

Example

- name: Site deploy
  hosts: all
  tasks:
    - name: Apply configuration
      ansible.builtin.template:
        src: app.conf.j2
        dest: "/etc/app/{{ region }}.conf"

Launched from a template with a region survey answer, every host paints its own cell in the matrix as the task lands.

See also Bash runs, Terraform runs, drift detection, and the tutorials.