* Don't use copy.deepcopy in high workload areas, use deepishcopy. ci_complete
* Add tests
* Add changelog fragment
* rename to naive_deepcopy and add extra docs
* Rename to module_response_deepcopy and move to vars/clean
* Provide a way to explicitly invoke the debugger with in the debug strategy
* Merge the debugger strategy into StrategyBase
* Fix some logic, pin to a single result
* Make redo also continue
* Make sure that if the debug closure doesn't need to process the result, that we still return it
* Fix failing tests for the strategy
* Clean up messages from debugger and exit code to match bin/ansible
* Move the FieldAttribute higher, to apply at different levels
* make debugger a string, expand logic
* Better host state rollbacks
* More explicit debugger prompt
* ENABLE_TASK_DEBUGGER should be boolean, and better docs
* No bare except, add pprint, alias h, vars to task_vars
* _validate_debugger can ignore non-string, that can be caught later
* Address issue if there were no previous tasks/state, and use the correct key
* Update docs for changes to the debugger
* Guard against a stat going negative through use of decrement
* Add a few notes about using the debugger on the free strategy
* Add changelog entry for task debugger
* Add a few versionadded indicators and a note about vars -> task_vars
* better cleanup on task results display
callbacks get 'clean' copy of result objects
moved cleanup into result object itself
removed now redundant callback cleanup
moved no_log tests
* moved import as per feedback
So I thought I fixed it before, but there's still one location where
the `rc` value is influential to decide whether a task failed or not.
We already established in #24867 that it is up to the module to decide
what the return code actually means, not the task executor. We modified
the existing modules to move that logic into the module (eg. for
command, shell, etc.)
This relates to the integration tests of win_robocopy, where different
return codes have different meanings:
- 0 -- No files copied.
- 1 -- Files copied successfully! (changed)
- 2 -- Some Extra files or directories were detected. No files were copied. (warning)
- 3 -- (2+1) Some files were copied. Additional files were present. (changed)
- 4 -- Some mismatched files or directories were detected. Housekeeping might be required! (changed + warning)
- 5 -- (4+1) Some files were copied. Some files were mismatched. (changed + warning)
- 6 -- (4+2) Additional files and mismatched files exist. No files were copied. (warning)
- 7 -- (4+1+2) Files were copied, a file mismatch was present, and additional files were present. (changed + warning)
- 8 -- Some files or directories could not be copied! (changed + failed)
- 9 - 15 -- Fatal error. Check log message! (failed)
- 16 -- Serious Error! No files were copied! Do you have permissions to access $src and $dest? (failed)
This also fixes#24652
Fix 'task name is not templated in retry callback'
Add a task_name property to TaskResult that knows to
check in TaskResult._task_fields.
Add integration test for v2_retry_runner callback
Fixes#18236
When a task result has an empty results list, the
list should be ignored when determining the results
of `_check_key`. Here the empty list is treated the
same as a non-existent list.
This fixes a bug that manifests itself with squashed
items - namely the task result contains the correct
value for the key, but an empty results list. The
empty results list was treated as zero failures
when deciding which handler to call - so the task
show as a success in the output, but is deemed to
have failed when deciding whether to continue.
This also demonstrates a mismatch between task
result processing and play iteration.
A test is also added for this case, but it would not
have caught the bug - because the bug is really in
the display, and not the success/failure of the
task (visually the test is more accurate).
Fixesansible/ansible-modules-core#4214
This changeset addresses the issue reported here:
ansible/ansible-modules-core#1765
The yum module (at least) includes its task results as strings, rather than
dicts, and the code this changeset replaces assumed that in that instance the
task was skipped. The updated behaviour assumes that the task has been
skipped only if:
* results exist, and
* all results are dicts that include a truthy skipped value
* fixed a bug in which failures from a with_* loop were not being
caught correctly, leading to tasks continuing when they should stop
* when ignore_errors is enabled, the failure will no longer count
towards the number of failed tasks
