Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix up a couple of references to 'only_if' and change them to 'when' #2826

Merged
merged 1 commit into from
May 2, 2013
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion docsite/latest/rst/playbooks.rst
Original file line number Diff line number Diff line change
Expand Up @@ -430,7 +430,7 @@ inside another.
this, consider how you can restructure your playbook to be more
class/role oriented. This is to say you cannot use a 'fact' to
decide what include file to use. All hosts contained within the
play are going to get the same tasks. ('only_if' provides some
play are going to get the same tasks. ('*when*' provides some
ability for hosts to conditionally skip tasks).

Roles
Expand Down
4 changes: 2 additions & 2 deletions docsite/latest/rst/playbooks2.rst
Original file line number Diff line number Diff line change
Expand Up @@ -288,7 +288,7 @@ there will be accessible to future tasks::
action: site_facts
- action: command echo {{ my_custom_fact_can_be_used_now }}

One common useful trick with only_if is to key off the changed result of a last command. As an example::
One common useful trick with *when* is to key off the changed result of a last command. As an example::

tasks:
- action: template src=/templates/foo.j2 dest=/etc/foo.conf
Expand Down Expand Up @@ -700,7 +700,7 @@ Often in a playbook it may be useful to store the result of a given command in a
it later. Use of the command module in this way can in many ways eliminate the need to write site specific facts, for
instance, you could test for the existance of a particular program.

The 'register' keyword decides what variable to save a result in. The resulting variables can be used in templates, action lines, or only_if statements. It looks like this (in an obviously trivial example)::
The 'register' keyword decides what variable to save a result in. The resulting variables can be used in templates, action lines, or *when* statements. It looks like this (in an obviously trivial example)::

- name: test play
hosts: all
Expand Down