James Cammarata 5b87951d6c Don't copy the parent block of TaskIncludes when loading statically ... When loading an include statically, we previously were simply doing a copy() of the TaskInclude object, which recurses up the parents creating a new lineage of objects. This caused problems when used inside load_list_of_blocks as the new parent Block of the new TaskInclude was not actually in the list of blocks being operated on. In most circumstances, this did not cause a problem as the new parent block was a proper copy, however when used in combination with PlaybookInclude (which copies conditionals to the list of blocks loaded) this untracked parent was not being properly updated, leading to tasks being run improperly. Fixes #18206		2016-11-11 08:09:43 -06:00
..
action	Fix bug (#18355) where encrypted inventories fail 18355 (#18373)	2016-11-07 10:07:26 -05:00
cache	Remove direct calls to print and cleanup imports	2016-11-07 17:12:36 -05:00
callback	ansible-logstash-callback (#18282)	2016-11-08 11:17:05 -05:00
connection	ANSIBLE_SSH_CONTROL_PATH_DIR option added (#18342)	2016-11-03 15:19:59 -07:00
filter	Add 'type' filter for display the underlying python type of a variable (#18242)	2016-10-31 13:36:24 -07:00
lookup	ini lookup: add 'default' to the list of parsed keys	2016-11-08 11:07:33 -05:00
shell	Move uses of to_bytes, to_text, to_native to use the module_utils version (#17423)	2016-09-06 22:54:17 -07:00
strategy	Don't copy the parent block of TaskIncludes when loading statically	2016-11-11 08:09:43 -06:00
test	restored 'results' filters	2016-10-13 13:21:40 -04:00
vars	Making the switch to v2	2015-05-03 21:47:26 -05:00
__init__.py	Filter out internal magic and connection variables from facts returns	2016-10-24 17:27:43 -05:00