Skipping via tags on role yields lots of errors

[memelet]

This is related #101, #102, #108 I think.

When I run

  roles:
    - role: cis
      when: a_var_that_false|bool == false

I get errors for all the places where there is no default for an array, eg

TASK [cis : 8.2.4.2 Create and Set Permissions on rsyslog Log Files (Scored)] **
[DEPRECATION WARNING]: Skipping task due to undefined Error, in the future this will be a fatal error.: 'dict object' has no attribute 'stdout_lines'.
This feature will be removed in a
future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: Skipping task due to undefined Error, in the future this will be a fatal error.: 'dict object' has no attribute 'stdout_lines'.
This feature will be removed in a
future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.
[DEPRECATION WARNING]: Skipping task due to undefined Error, in the future this will be a fatal error.: 'dict object' has no attribute 'stdout_lines'.
This feature will be removed in a
future release. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

The PR that was ultimately applied I think only works for check mode but not when tasks are skipped like above for via --skip-tags.

So I think the PR https://github.com/awailly/cis-ubuntu-ansible/pull/102 is still required.

We have been running with a branch that has had this applied for a long time. Just today I tried to using master and get gobs and gobs of errors.

[memelet]

Hmm, I think I misunderstood what happening. I still get the above errors even with mods like

- name: 8.2.4.2 Create and Set Permissions on rsyslog Log Files (Scored)
    shell: 'mkdir -p -- "$(dirname -- {{ item }})"; touch -- {{ item }}' 
    with_items: "{{result.stdout_lines | default([])}}"
    changed_when: False
    register: rsyslog_files_created
    tags:
      - section8
      - section8.2
      - section8.2.4

(note the | default([]) in the with_items)

So maybe it's even worse now with 2.1.2.0. Before the default was enough, now default is not strong enough to overcome result not being set by the skipped task.

[memelet]

Oh boy, this is nasty. Here is one way to get rid of the warning:

    with_items: "{{ (result | default([])).stdout_lines | default([]) }}"

But just wait, maybe with next version of ansible this fix will get even worse.

[memelet]

~It can be cleaned a bit with the var~

result_or_empty: "{{ (result | default([])).stdout_lines | default([]) }}"

then

    with_items: "{{ result_or_empty }}"

The above does not really work because there are lots these warnings using different variable names and sometimes different list properties.

So, I hope there is some desire here to eliminate these kinds of warnings not only in check mode but also when skipping. ~Not saying any of the above are good solutions just yet~, but I would least like to get some confirmation that some fix would be accepted.

Reference: https://groups.google.com/forum/?fromgroups=#!searchin/ansible-project/DEPRECATION$20WARNING$20$27dict$20object$27$20has$20no$20attribute%7Csort:relevance/ansible-project/Jna4VKyGZWM/NGAKOiUWKQAJ

So really the ugly syntax is the only way to handle with_items when the task that sets the loop variable did not execute.

[memelet]

The commit above is what i had to do eliminate the errors. Pretty much what my original PR was, but a big uglier. Shall I submit as a PR?

[awailly]

@memelet Yes totally, I more inclined to accept PR now that I understand the issue!