Goal
Add a filter for ansible-playbook — one of the most widely used configuration management and automation tools, with notoriously verbose CI output.
Background
Every Ansible task emits at minimum two lines per host: the task name header and the result. A playbook with 100 tasks across 50 hosts generates 5,000+ lines, the vast majority being ok: [hostname] (no change occurred). In CI, these overwhelm the actual signal.
The meaningful lines are:
changed: [hostname] — something was modified (worth knowing)
failed: [hostname] — something broke (critical)
fatal: [hostname] — unrecoverable failure (critical)
PLAY RECAP — the final summary
ok and skipping lines represent zero new information in post-run review.
Filters to Add
ansible/playbook.toml — ansible-playbook
- Skip:
ok: [hostname] result lines
skipping: [hostname] result lines
TASK [role : task name] ****... header lines for tasks that resulted in ok or skipping
- Keep:
changed: [hostname] result lines (with their preceding task header)
failed: [hostname] result lines (with preceding task header)
fatal: [hostname] result lines
PLAY RECAP section and all lines within it
PLAY [play name] headers
- Lines containing
msg: from failed tasks (the error message)
Consider section parsing: track each TASK [...] header, then decide to keep or discard based on whether the result line is ok/skipping vs changed/failed/fatal.
ansible/lint.toml — ansible-lint
- Skip:
[WARNING] lines from rules at warning severity when error level violations exist
- Keep: All violation lines with rule ID and file:line reference, summary
Fixture Files Needed
tests/fixtures/ansible/playbook-allok.txt — large playbook run with all tasks ok
tests/fixtures/ansible/playbook-changes.txt — playbook with mix of ok, changed, skipping
tests/fixtures/ansible/playbook-failure.txt — playbook with a task failure
tests/fixtures/ansible/lint-violations.txt — ansible-lint output with errors and warnings
Acceptance Criteria
Goal
Add a filter for
ansible-playbook— one of the most widely used configuration management and automation tools, with notoriously verbose CI output.Background
Every Ansible task emits at minimum two lines per host: the task name header and the result. A playbook with 100 tasks across 50 hosts generates 5,000+ lines, the vast majority being
ok: [hostname](no change occurred). In CI, these overwhelm the actual signal.The meaningful lines are:
changed: [hostname]— something was modified (worth knowing)failed: [hostname]— something broke (critical)fatal: [hostname]— unrecoverable failure (critical)PLAY RECAP— the final summaryokandskippinglines represent zero new information in post-run review.Filters to Add
ansible/playbook.toml—ansible-playbookok: [hostname]result linesskipping: [hostname]result linesTASK [role : task name] ****...header lines for tasks that resulted inokorskippingchanged: [hostname]result lines (with their preceding task header)failed: [hostname]result lines (with preceding task header)fatal: [hostname]result linesPLAY RECAPsection and all lines within itPLAY [play name]headersmsg:from failed tasks (the error message)Consider section parsing: track each
TASK [...]header, then decide to keep or discard based on whether the result line isok/skippingvschanged/failed/fatal.ansible/lint.toml—ansible-lint[WARNING]lines from rules atwarningseverity whenerrorlevel violations existFixture Files Needed
tests/fixtures/ansible/playbook-allok.txt— large playbook run with all tasksoktests/fixtures/ansible/playbook-changes.txt— playbook with mix ofok,changed,skippingtests/fixtures/ansible/playbook-failure.txt— playbook with a task failuretests/fixtures/ansible/lint-violations.txt— ansible-lint output with errors and warningsAcceptance Criteria
ok:andskipping:task result lines removed from outputchanged:lines and their task headers preservedfailed:/fatal:lines and their task headers and error messages preservedPLAY RECAPsection always fully preserved