avoid making gathered facts high precedence, only set_fact is supposed to be.
vars set via set_fact with cacheable are higher precedence than plain facts.
Previously (after 6fbd0a8bb5) regular facts would end up with a
higher precedence than host or play vars, but they should not be. Facts were getting added to 'non_persistent_facts' (equivalent to 'register' vars) which is higher precedence than facts should be.
added 'cacheable set_facts' to precedence docs
'ansible_facts_cacheable' -> '_ansible_facts_cacheable' (made 'private')
We made this change a couple of months ago, deprecating community.html in favor of community/index.html and its full guide, but the change was never made here in the index.
* Correct formatting
* Use RST :option:
* ansible-pull --vault-password-file
* Streamlined the language a bit in the intro.
* Exclamation point removal!
* Add openssh-client to default docker container.
* Include Azure requirements in default container.
To do so, handling of pip requirements was updated to install each
set of requirements separately and then run a verification pass to
make sure there are no conflicts between requirements.
* Add missing --docker-no-pull option.
* Add documentation for the azure-requirements test.
* new documentation for unit testing - especially module unit testing
* unit test documentation reformatting and further fixes
* unit test documentation - point to online coverage reports & fix bad spaces
* Small copy edits.
* First pass copy edit / rewrite. More info needed.
* testing documentation - clean up structure, especially code coverage - reduce repetition
* module unit test documentation - improved introduction
* testing documentation - more fixes from and inspired by review from dharmabumstead
* testing documentation - fixes from mattclay + some other minor tweaks
* More copy edits.
* testing documentation - further fixes from review
* Copy edits
* Copy edits
* More copy edits.
* first round of splitting and expanding Windows docs
* Added info about WinRM and started the usage page
* more details onf usage around command/shell
* added more info
* missed a page
* added info about hotfix and ps upgrade script
* Added DSC information
* filled in FAQ and fixed up links
* changes per PR review and typo fixes found by myself
* fixed sanity check
* updated external script URLS
* Edits
* Edits
* Edits
* Copy edits.
* More copy edits.
* Added info about becoming a local service account
* some formatting changes on become and DSC indent fix
* Copy edits/rewrites
* Copy edits/rewrites
* minor updates to UAC text, typos
* minor wording updates
* minor wording tweaks/typos
* minor wording tweaks/typos
* minor tweaks/typos
* fix indent issue
* fix title underline length
* fix quote issue
* fixed module generation
added missing lookup page
point to plugins when plugins
made modules singular
add display for verbose an debug messages
nicer templating, changed generation order for ref
corrected links
moved most of lookup docs to plugin section
* Copy edits
* Fixed typos
* Clarified wording
- old functionality is still available direct lookup use, the following are equivalent
with_nested: [[1,2,3], ['a','b','c']]
loop: "{{lookup('nested', [1,2,3], ['a','b','c'])}}"
- avoid squashing with 'loop:'
- fixed test to use new intenal attributes
- removed most of 'lookup docs' as these now reside in the plugins
this should allow user to control how they want the playbook dirs inspected
for additional vars, default now reverts to 2.3 behaviour (top).
corrected paths order
minor doc reword
* Improve and link Network Proxy docs
It is possible for proxy issues to cause "unable to open shell", so
detail there.
Having the "how-to" in the debug page makes more sense than on the
porting page, so move it.
Fixed a few formatting issues at the same time.
* Edits
* typo
It's almost always preferable to clone by way of https:// rather than
using the bare git:// protocol. Not only does https:// provide
stronger guarantees it also plays nicer with corporate proxies, etc.
* Update playbooks_blocks.rst
The rescue section documentation should be clear that successful completion of a rescue section will override other error handling behavior.
* more precise rescue docs
explains in detail the consequences of successful rescue
