Please understand I believe my answer to be highly subjective. Internally my team loosely agrees with my opinions on this. But we've not draft any "formatting policy" for playbooks.
- Should name (
name
) be used or a comment (#
)?
We only include comments if it is useful to explain the "why?" of the particular task. name
is always present. The value of name
will be displayed during the playbook run. In cases where a role is used as a dependency, I often parameterized name
. A couple examples.
Parameterized name
example, from roles/some_container/meta/main.yml
...
dependencies:
- { role: remove_container, container_name: some_container }
...
roles/remove_container/tasks/main.yml
...
- name: Remove containers - {{ container_name }}
docker_container:
name: "{{ container_name }}"
state: absent
force_kill: true
...
Comments as complimentary to name
. roles/remove_image/tasks/main.yml
# The 'docker_image' module, as of EPEL build 2.1.0.0, does not correctly handle 'tag: *' for removing all image tags.
# Below is not pretty but works on systems where you know all the image names.
- name: Remove images - {{ image_name }}
shell: docker rmi -f $(docker images | grep {{ image_name }} | awk '{print $3}')
register: result
changed_when: "'requires a minimum of 1 argument' not in result.stderr"
failed_when:
- "'requires a minimum of 1 argument' not in result.stderr"
- "result.rc != 0"
- Should it be [k=v] or [k: v]?
I always use the 'k: v' syntax. Additionally I break separate values with a new line. When reading a play where someone has stuffed many 'k=v' on a single line my brain gets twisted up. I find it very difficult to juggle all the keys/values as I read along for the ones I'm interested.
Which is easier to read? I think the second example.
# 1. Launch container k=v
- name: Start A container
docker_container:
name=containerA image=imageA published_ports='443:8443' exposed_ports=8443 volumes='/some/path:/some/path' links='b:b' env='/some/local.fact' pull=false restart_policy=always state=started
# 2. Launch container k: v
- name: Start api container
docker_container:
name: containerA
image: imageB
published_ports:
- "443:8443"
exposed_ports:
- 8443
volumes:
- /some/path:/some/path
links:
- db:db
env: /some/local.fact
pull: false
restart_policy: always
state: started
I also make judicious use of white space at times.
...
# Containers a, b, c comprise 'app d' and can be updated independently.
roles:
- { role: bootstrap_common, tags: bootstrap }
- { role: bootstrap_a, tags: bootstrap }
- { role: bootstrap_b, tags: bootstrap }
- { role: deploy_container_a, tags: a }
- { role: deploy_container_b, tags: b }
- { role: deploy_container_c, tags: c }
...
#Assign value 5 to numberOfCoins
next to the lineint numberOfCoins = 5;
in a programming language. There's no point in adding comments to code which is already self-documenting, and some take the view that it is actually harmful (it adds maintenance, and opportunities for confusion if the comments fall out of sync with code that has changed).