ansible.builtin.junit callback – write playbook output to a JUnit file.
Note
This callback plugin is part of ansible-core
and included in all Ansible
installations. In most cases, you can use the short
plugin name
junit
.
However, we recommend you use the Fully Qualified Collection Name (FQCN) ansible.builtin.junit
for easy linking to the
plugin documentation and to avoid conflicting with other collections that may have
the same callback plugin name.
Callback plugin
This plugin is an aggregate callback. It adds additional console output next to the configured stdout callback. See Callback plugins for more information on callback plugins.
Synopsis
This callback writes playbook output to a JUnit formatted XML file.
Tasks show up in the report as follows: ‘ok’: pass ‘failed’ with ‘EXPECTED FAILURE’ in the task name: pass ‘failed’ with ‘TOGGLE RESULT’ in the task name: pass ‘ok’ with ‘TOGGLE RESULT’ in the task name: failure ‘failed’ due to an exception: error ‘failed’ for other reasons: failure ‘skipped’: skipped
Requirements
The below requirements are needed on the local controller node that executes this callback.
enable in configuration
Parameters
Parameter |
Comments |
---|---|
Consider any tasks reporting “changed” as a junit test failure Default: Configuration:
|
|
Consider failed tasks as a junit test failure even if ignore_on_error is set Default: Configuration:
|
|
Hide the arguments for a task Default: Configuration:
|
|
Should the setup tasks be included in the final report Default: Configuration:
|
|
Directory to write XML files to. Default: Configuration:
|
|
Replace the directory portion of an out-of-tree relative task path with the given placeholder Default: Configuration:
|
|
Configure the output to be one class per yaml file Default: Configuration:
|
|
Configure the output to use relative paths to given directory Default: Configuration:
|
|
Consider a task only as test case if it has this value as prefix. Additionally failing tasks are recorded as failed test cases. Default: Configuration:
|
Hint
Configuration entries for each entry type have a low to high priority order. For example, a variable that is lower in the list will override a variable that is higher up.