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

Conditions are not respected when inspecting tasks in a block #1894

Closed
nre-ableton opened this issue Feb 14, 2022 · 7 comments
Closed

Conditions are not respected when inspecting tasks in a block #1894

nre-ableton opened this issue Feb 14, 2022 · 7 comments
Assignees
Labels

Comments

@nre-ableton
Copy link
Contributor

Summary

In #1809 (part of version 5.4.0), ansible-lint gained the ability to inspect tasks inside of a block. However, it doesn't look at the block's conditions when inspecting the task, which results in erroneous no-changed-when errors.

Issue Type
  • Bug Report
Ansible and Ansible Lint details
$ ansible --version
ansible [core 2.12.2]
  config file = None
  configured module search path = ['/home/nre/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/nre/.cache/virtualenv/ansible-role-ccache/lib/python3.9/site-packages/ansible
  ansible collection location = /home/nre/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/nre/.cache/virtualenv/ansible-role-ccache/bin/ansible
  python version = 3.9.7 (default, Sep 10 2021, 14:59:43) [GCC 11.2.0]
  jinja version = 3.0.2
  libyaml = True

$ ansible-lint --version
ansible-lint 5.4.0 using ansible 2.12.2
  • ansible installation method: pip
  • ansible-lint installation method: pip
OS / ENVIRONMENT

Ubuntu Linux 20.04

STEPS TO REPRODUCE

For an example, see the build-sources.yml task file of the ableton.ccache role here. An abbreviated version of this file follows:

---
- name: Check ccache version
  command: "ccache --version"
  environment:
    PATH: "{{ ccache_install_prefix }}/bin:{{ ansible_pkg_mgr_path }}"
  changed_when: false
  failed_when: false
  register: ccache_version_cmd

- name: Build ccache from sources
  block:
    - name: Run configure script
      command: "./configure --prefix={{ ccache_install_prefix }}"
      args:
        chdir: "{{ ccache_build_dir }}/ccache-{{ ccache_version }}"

    - name: Build ccache
      command: "make -j{{ ccache_make_jobs }}"
      args:
        chdir: "{{ ccache_build_dir }}/ccache-{{ ccache_version }}"

    - name: Install ccache
      become: true
      command: "make install"
      args:
        chdir: "{{ ccache_build_dir }}/ccache-{{ ccache_version }}"
  when: >
    ccache_version_cmd.rc != 0 or
    ccache_version not in ccache_version_cmd.stdout_lines[0]

In a block, conditions are applied to each task implicitly. But for the above code, ansible-lint emits a no-changed-when violation because it doesn't realize that the command tasks actually do have a condition attached to them.

Desired Behavior

no-changed-when shouldn't be raised when tasks are inside of a block, and that block has a when condition.

@ssbarnea
Copy link
Member

AFAIK you must use changed_when to help ansible determine the changed status on any task, regardless if is inside a block or not. Whatever conditions are at block level, they do not change the need to set changed_when.

@nre-ableton
Copy link
Contributor Author

I don't think this has anything to do with changed_when. From my above example, the following code does not emit no-changed-when errors with ansible-lint 5.4.0:

---
- name: Check ccache version
  command: "ccache --version"
  environment:
    PATH: "{{ ccache_install_prefix }}/bin:{{ ansible_pkg_mgr_path }}"
  changed_when: false
  failed_when: false
  register: ccache_version_cmd

- name: Run configure script
  command: "./configure --prefix={{ ccache_install_prefix }}"
  args:
    chdir: "{{ ccache_build_dir }}/ccache-{{ ccache_version }}"
  when: >
    ccache_version_cmd.rc != 0 or
    ccache_version not in ccache_version_cmd.stdout_lines[0]

- name: Build ccache
  command: "make -j{{ ccache_make_jobs }}"
  args:
    chdir: "{{ ccache_build_dir }}/ccache-{{ ccache_version }}"
  when: >
    ccache_version_cmd.rc != 0 or
    ccache_version not in ccache_version_cmd.stdout_lines[0]

- name: Install ccache
  become: true
  command: "make install"
  args:
    chdir: "{{ ccache_build_dir }}/ccache-{{ ccache_version }}"
  when: >
    ccache_version_cmd.rc != 0 or
    ccache_version not in ccache_version_cmd.stdout_lines[0]

But, placing the last three tasks in a block causes no-changed-when to be emitted, which is equivalent to how block behaves. According to the documentation:

The directive does not affect the block itself, it is only inherited by the tasks enclosed by a block. For example, a when statement is applied to the tasks within a block, not to the block itself.

See also: https://everythingshouldbevirtual.com/automation/Ansible-Blocks-With-Conditionals/

@ssbarnea
Copy link
Member

@cognifloyd Do you think you could add a fix for this one? It is a side effect of #1809 and I suspect we need to inherit stuff like when from parent blocks when normalizing.

In fact I think that the same issue prevents collection name resolution from working like when you define collections: but later fail to resolve non FQCN on tasks.

@cognifloyd
Copy link
Contributor

Fascinating. I suppose that makes sense. Normalizing like that has implications for the future transforms feature as well. To be able to fix conditions they would need the whole file instead of just the target task.

I probably won't get to this today, but I do want to fix this.

@ssbarnea
Copy link
Member

ssbarnea commented Oct 1, 2022

Unable to reproduce with current versions.

@ssbarnea ssbarnea closed this as completed Oct 1, 2022
@nre-ableton
Copy link
Contributor Author

@ssbarnea Sorry, but the issue is still reproducible with ansible-ilnt 6.8.0b1.

@nre-ableton
Copy link
Contributor Author

@ssbarnea Did you see my above comment? This issue is still present in 6.8.2 and can be reproduced with the example code in the issue description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Done
Development

No branches or pull requests

3 participants