whitecloud / ansible-styleguide Goto Github PK

Hi,

Before contributing or using it: What are the terms when contributing or using your styleguide?

There is no LICENSE, COPYING file nor anything mentioned in CONTRIBUTING.md.

Apache 2.0 would be reasonable in an Ansible context, I guess.

Thanks,
Andreas

As someone who has a suggestion for a new rule in the guide, what should I do to suggest it? Should I spend the time to create PR? Should I open an issue? Complain about it on Twitter? What do the maintainers want? I was looking for CONTRIBUTING.md or similar. https://github.com/blog/1184-contributing-guidelines

As https://github.com/whitecloud/ansible-styleguide#quotes stated, single quotes should be preferred for strings; double quotes are only allowed if embedded in Jinja templates. But it seems that I found an exception from my work where only double quotes work, but single quotes do not.

# test.yml
---

- name: test special quote cases
  hosts: localhost
  vars:
    tabbed_strings:
      - "aaa\t111"
      - "bbb\t222"
      - "ccc\t333"
  tasks:
    - name: double quotes work
      debug:
        msg: "{{ item.split('\t')[0] }}" 
      loop: "{{ tabbed_strings }}"

    - name: single quotes don't work
      debug:
        msg: '{{ item.split("\t")[0] }}'
      loop: '{{ tabbed_strings }}'

Output:

➜ ansible-playbook test.yml -v
Using /home/sqyu/code/greatdb-ansible/ansible.cfg as config file

PLAY [test special quote cases] ***********************************************************************************************************************************************************************************

TASK [double quotes work] *****************************************************************************************************************************************************************************************
ok: [localhost] => (item=aaa    111) => 
  msg: aaa
ok: [localhost] => (item=bbb    222) => 
  msg: bbb
ok: [localhost] => (item=ccc    333) => 
  msg: ccc

TASK [single quotes don't work] ***********************************************************************************************************************************************************************************
ok: [localhost] => (item=aaa    111) => 
  msg: "aaa\t111"
ok: [localhost] => (item=bbb    222) => 
  msg: "bbb\t222"
ok: [localhost] => (item=ccc    333) => 
  msg: "ccc\t333"

PLAY RECAP ********************************************************************************************************************************************************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0 

The output shows that the split() function doesn't work for single-quoted strings.

Why do I use double quotes for tabbed_strings in the above case? Because I found it is how Ansible's register produces strings from stdout.

The official Ansible YAML syntax documentation stated that single quotes don't work with escape characters.

In practice I find the current "Role Declaration" rule (create a task file named to match the role, then include that file in a main.yml that does nothing else) to be boilerplate-heavy, forcing an include right off the bat to address what's generally an editor issue ("having several main.yml files open at once can get very confusing".) It also encourages a single task file per role, which in larger roles may not be the right structure... as to name a task file otherwise contradicts the role name, so it seems people generally just append more and more to the task file.

I prefer we don't favor boilerplate to fix editor issues in favor of purposeful use of multiple files, so I recommend we strike "Role Declation" in favor of well-documented main.yml, then fragmenting into multiple task .yml files as needed, none of them named the same as the role itself.

Is there any guidance on designing tasks that would ignore errors?

I read task output like this:

TASK [whatever : Shut down something] **********************************************
fatal: [10.140.2.225]: FAILED! => {"changed": false, "failed": true, "msg": "systemd could not find the requested service "'something'": "}
...ignoring

in red and my first thought is WHY is that ignored?

Would it make sense to have guidelines around naming of the task to include the reason for ignored error?, as extra assurance that this is is an 'expected exception' not just a patch around an error condition we don't understand?

E.g. here, if the task was named "Shut down something, ignore since user may have already shut it down" I might feel better.

Or perhaps something is wrong at a higher level with this pattern... perhaps we should have guidance that ignore should never be used UNLESS it is expected exception. It still does end up being red output. :(