Options to modify --diff behavior

Is it possible to pass options to ansible-playbook’s --diff processor? In particular, I’d like to have it ignore whitespace changes.

Normally this isn’t an issue, but I’m diffing a rather involved .conf file that’s been maintained by hand for years and converting it to be generated from config data via ansible.builtin.template. I’m getting to the point where the majority of the differences are due to the inconsistent spacing that’s crept in over the years, but the content is mindnumbingly tedious. It can take a minute or two to verify that a particular section only differs in spacing.

If there’s a way, please, make my day! Thanks.

Why don’t you slurp the files and then then convert them into JSON using either the JC ini parser or the JC ini duplicate parser via the JC filter and then compare them?

I’d suggest you might also want to consider using the ini module to update the files as this allows comments to be preserved.

FWIW this is the approach I have used for both PHP and MariaDB roles as both use INI files.


Thanks for the suggestions, @chris . Those are all useful techniques. Another is to set the template dest: to a temporary file on the target host and use the native diff with appropriate options. That’s what I’m doing now to work around the build-in diff’s missing control knobs.

Given that ansible-playbook is already doing a diff of some sort, giving the user some say in the options used seems a reasonable ask. Evidently that isn’t possible at the moment. Perhaps a feature request is in order.

I’ll mark your comment as the “solution” even though it’s more of a work-around. “No but …” is as good as we can get for now.


difflib (the library used by most callbacks to compute diffs) generates standard unified diffs but does not really have any options to expose.

A couple of different proofs of concept for calling an external full-featured diff tool are floating around (e.g. RFE: Option to ignore whitespace difference in --diff mode · Issue #14674 · ansible/ansible · GitHub) but no one has ever finished the implementations/opened a PR.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.