Instead of having to remember when to use which one, rename template_ds
to template and move the last bit of code from template to varReplace
(which gets used for all string replacements, in the end).
This means that you can template any data type without worrying about
whether it's a string or not, and the right thing will happen.
global_vars has higher precedence than inventory. Putting the all
group's variables into it overrides all other groups and hosts.
Partially fixes#1647.
Executive summary: skipping a host corrupts a variable (when it is registered)
We have a play existing out of multiple tasks that check a condition, if one of these tasks fails we want to skip all next tasks in the playbook. I noticed that if we skip a task because a certain condition is met, and this task has a register-attribute, I loose the value in the variable. Which means we cannot use that variable in subsequent tasks to evaluate because it was skipped:
```
- action: command test -d /some/directory
register: task
- action: command test -f /some/directory/file
register: task
only_if: '${task.rc} == 0'
- action: do something else
only_if: '${task.rc} == 0'
```
In the above example, if the second task is skipped (because the first failed), the third action will end with a "SyntaxError: invalid syntax" complaining about the unsubstituted ${task.rc} (even though it was set by the first task and used for skipping the second).
The following play demonstrates the problem:
```
- name: Test register on ignored tasks
hosts: all
gather_facts: no
vars:
skip: true
task: { 'rc': 666 }
tasks:
- action: debug msg='skip = ${skip}, task.rc = ${task.rc}'
- name: Skip this task, just to test if task has changed
action: command ls
register: task
only_if: '${skip} != True'
- action: debug msg='skip = ${skip}, task.rc = ${task.rc}'
- name: Now use task value
action: command echo 'Works !'
only_if: '${task.rc} == 0'
```
And the enclosed fix, fixes the above problem.
After spending 10 minutes to find which playbook had an action/local_action missing, I changed the error to include the task name (if set). The error eventually was caused because I added a name to a task, but the dash before the existing action was not removed.
