community.general.default_without_diff callback – The default ansible callback without diff output

Note

This callback plugin is part of the community.general collection (version 10.1.0).

You might already have this collection installed if you are using the ansible package. It is not included in ansible-core. To check whether it is installed, run ansible-galaxy collection list.

To install it, use: ansible-galaxy collection install community.general.

To use it in a playbook, specify: community.general.default_without_diff.

New in community.general 8.4.0

Callback plugin

This plugin is a stdout callback. You can use only use one stdout callback at a time. Additional aggregate or notification callbacks can be enabled though. See Callback plugins for more information on callback plugins.

Synopsis

  • This is basically the default ansible callback plugin (ansible.builtin.default) without showing diff output. This can be useful when using another callback which sends more detailed information to another service, like the ARA callback, and you want diff output sent to that plugin but not shown on the console output.

Parameters

Parameter

Comments

check_mode_markers

boolean

added in Ansible 2.9

Toggle to control displaying markers when running in check mode.

The markers are DRY RUN at the beginning and ending of playbook execution (when calling ansible-playbook --check) and CHECK MODE as a suffix at every play and task that is run in check mode.

Choices:

  • false ← (default)

  • true

Configuration:

display_failed_stderr

boolean

added in Ansible 2.7

Toggle to control whether failed and unreachable tasks are displayed to STDERR rather than STDOUT.

Choices:

  • false ← (default)

  • true

Configuration:

display_ok_hosts

boolean

added in Ansible 2.7

Toggle to control displaying ‘ok’ task/host results in a task.

Choices:

  • false

  • true ← (default)

Configuration:

display_skipped_hosts

boolean

Toggle to control displaying skipped task/host results in a task.

Choices:

  • false

  • true ← (default)

Configuration:

pretty_results

boolean

added in ansible-core 2.13

Configure the result format to be more readable.

When result_format is set to yaml this option defaults to true, and defaults to false when configured to json.

Setting this option to true will force json and yaml results to always be pretty printed regardless of verbosity.

When set to true and used with the yaml result format, this option will modify module responses in an attempt to produce a more human friendly output at the expense of correctness, and should not be relied upon to aid in writing variable manipulations or conditionals. For correctness, set this option to false or set result_format to json.

Choices:

  • false

  • true

Configuration:

result_format

string

added in ansible-core 2.13

Define the task result format used in the callback output.

These formats do not cause the callback to emit valid JSON or YAML formats.

The output contains these formats interspersed with other non-machine parsable data.

Choices:

  • "json" ← (default)

  • "yaml"

Configuration:

show_custom_stats

boolean

This adds the custom stats set via the set_stats plugin to the play recap.

Choices:

  • false ← (default)

  • true

Configuration:

show_per_host_start

boolean

added in Ansible 2.9

This adds output that shows when a task starts to execute for each host.

Choices:

  • false ← (default)

  • true

Configuration:

show_task_path_on_failure

boolean

added in ansible-core 2.11

When a task fails, display the path to the file containing the failed task and the line number. This information is displayed automatically for every task when running with -vv or greater verbosity.

Choices:

  • false ← (default)

  • true

Configuration:

Examples

# Enable callback in ansible.cfg:
ansible_config: |
  [defaults]
  stdout_callback = community.general.default_without_diff

# Enable callback with environment variables:
environment_variable: |
  ANSIBLE_STDOUT_CALLBACK=community.general.default_without_diff

Authors

  • Felix Fontein (@felixfontein)

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.