The function is Ansible >= 12 (ansible-core >= 2.19). See #1274 for analysis
of `json.dumps()` vs `jsonify()` differences. This change is a middle ground
between full backward compatibility and using `json.dumps()` unadorned.
- if `data` is `None`, then it will still be transferred as `{}` on older
versions of Ansible, but 'null' in newer releases. Cases where 'null'
caused a problem are suspected/reported, but no reproducers are available.
- `ensure_ascii=True` will be still be tried, with fallback. I believe this
is only relevant on Python 2.x.
- `sort_keys=True` will no longer be used.
- No indentation/pretty printing will be applied, this remains unchanged
fixes#1274
Python 2.7 (distro package) and 3.6 (pyenv managed) jobs run on Ubuntu 22.04.
More recent Pythons (distro or Github provided) run on 24.04.
fixes#1256
Ansible tasks that run locally (e.g. `connection: local`, `delegate_to:
localhost`) must now specify their `ansible_python_interpreter`, typically as
`{{ ansible_playbook_python }}`; otherwise the system Python on the controller
(e.g. `/usr/bin/python`) is likely to be used and this is often outside the
version range supported by the Ansible verison under test. If this occurs then
the symptom is often a failure to import a builtin from
`ansible.module_utils.six.moves`, e.g.
```
fatal: [target-centos6-1]: FAILED! => changed=true
cmd:
- ansible
- -m
- shell
- -c
- local
- -a
- whoami
- -i
- /tmp/mitogen_ci_ansibled3llejls/hosts
- test-targets
delta: '0:00:02.076385'
end: '2025-04-17 17:27:02.561500'
msg: non-zero return code
rc: 8
start: '2025-04-17 17:27:00.485115'
stderr: |-
stderr_lines: <omitted>
stdout: |-
An exception occurred during task execution. To see the full traceback,
use -vvv. The error was: from ansible.module_utils.six.moves import
map, reduce, shlex_quote
```
Each grouping gets an independant dir, e.g.
- ansible -> /tmp/mitogen_ci_ansible
- debops -> /tmp/mitogen_ci_debops
Importing ci_lib no longer creates a temporary directory as a side effect.
This adapts PR #740 by @extmind (afe0026890),
which augmented the call to `Connection.get_task_var()` with
`C.config.get_config_value('INTERPRETER_PYTHON'` as a default. Instead this
*replaces* the call to `Connection.get_task_var()`. The aim is greater
simplicity by disentangling templating of a configured interpreter path and
discovery of an interpreter when none is configured. I think this also reduces
the number of times `Connection._get_task_vars()` is called, so reducing the
number of times we do the ugly stack frame inspection.
I've also added test cases.
Co-authored-by: Lars Beckers <lars@extmind.de>
Ansible >= 4 (ansible-core >= 2.11) the SSH plugin has a `timeout` option and
with variable `ansible_ssh_timeout`, but not a `ansible_timeout` variable.
The local plugin has no such option or variable(s). However `ansible_timeout`
is backfilled for all conection plugins, by legacy mechanisms that populate
the play context attribute:
- `ansible.constants.COMMON_CONNECTION_VARS`
- `ansible.constants.MAGIC_VARIABLE_MAPPING`
The `timeout` keyword is for task completion timeout, not connection timeout.
This tightens up our monkey patching `Connection._action` so it's only applied
during `meta: reset_connection` & promptly removed. This fixes "'int' object
has no attribute 'template'" when `ansible.plugins.action.wait_for_connection`
or other code calls `ansible.plugins.connection.ConnectionBase.reset()`.
This could also have switched to `templar=templar` on the temporary action,
rather than `templar=0`, but it's not strictly necessary to fix this bug. I
anticipate other changes doing so soon, to improve interpreter discovery &
templated python interpreter path support.