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

KeyError when fixing playbook containing multiple blocks with wrong key order #4091

Closed
zack-mayoh opened this issue Apr 4, 2024 · 4 comments · Fixed by #4116
Closed

KeyError when fixing playbook containing multiple blocks with wrong key order #4091

zack-mayoh opened this issue Apr 4, 2024 · 4 comments · Fixed by #4116
Assignees
Labels

Comments

@zack-mayoh
Copy link

zack-mayoh commented Apr 4, 2024

Summary

ansible-lint --fix breaks with a KeyError in the key-order rule when run on a yaml file containing multiple blocks where blocks after the first have incorrect key order.

Issue Type
  • Bug Report
OS / ENVIRONMENT
ansible-lint 6.22.2 using ansible-core:2.15.10 ansible-compat:4.1.11 ruamel-yaml:None ruamel-yaml-clib:None
  • ansible installation method: pip
  • ansible-lint installation method: pip
STEPS TO REPRODUCE

Run ansible-lint --fix on the following test playbook:

---
- name: Test multiple blocks with when in wrong order
  hosts: all
  tasks:
    - name: First block
      when: true
      block:
        - name: Test1
          ansible.builtin.debug:
            msg: Foo

- name: Second play
  hosts: all
  tasks:
    - name: Second block
      block:
        - name: Test2
          ansible.builtin.debug:
            msg: Baz
      when: true
Desired Behavior

Should fix the key order of the incorrect block without breaking.

Actual Behavior

Results of ansible-lint --fix:

$ ansible-lint --fix test.yml
Traceback (most recent call last):
  File "/usr/local/bin/ansible-lint", line 8, in <module>
    sys.exit(_run_cli_entrypoint())
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/__main__.py", line 402, in _run_cli_entrypoint
    sys.exit(main(sys.argv))
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/__main__.py", line 379, in main
    fix(runtime_options=options, result=result, rules=rules)
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/__main__.py", line 248, in fix
    _do_transform(result, options)
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/__main__.py", line 203, in _do_transform
    transformer.run()
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/transformer.py", line 118, in run
    self._do_transforms(file, ruamel_data or data, file_is_yaml, matches)
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/transformer.py", line 156, in _do_transforms
    match.rule.transform(match, file, data)
  File "/usr/local/lib/python3.9/site-packages/ansiblelint/rules/key_order.py", line 139, in transform
    task[key] = task.pop(key)
  File "/usr/local/lib/python3.9/site-packages/ruamel/yaml/comments.py", line 926, in pop
    result = self[key]
  File "/usr/local/lib/python3.9/site-packages/ruamel/yaml/comments.py", line 853, in __getitem__
    return ordereddict.__getitem__(self, key)
KeyError: 'when'

Results of ansible-playbook --syntax-check playbook:

$ ansible-playbook -i localhost, --syntax-check test.yml

playbook: test.yml
@zack-mayoh zack-mayoh added bug new Triage required labels Apr 4, 2024
@audgirka audgirka self-assigned this Apr 10, 2024
@audgirka audgirka removed the new Triage required label Apr 10, 2024
@kitos9112
Copy link

Just faced the same issue but with a notify keyword.

Traceback (most recent call last):
  File "/home/me/projects/ansible/provisioning/main/extension/setup/../../../../opt/tf-ansible-WA5-pL_2-py3.11/bin/ansible-lint", line 10, in <module>
    sys.exit(_run_cli_entrypoint())
             ^^^^^^^^^^^^^^^^^^^^^
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/__main__.py", line 400, in _run_cli_entrypoint
    sys.exit(main(sys.argv))
             ^^^^^^^^^^^^^^
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/__main__.py", line 377, in main
    fix(runtime_options=options, result=result, rules=rules)
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/__main__.py", line 246, in fix
    _do_transform(result, options)
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/__main__.py", line 207, in _do_transform
    transformer.run()
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/transformer.py", line 113, in run
    self._do_transforms(file, ruamel_data or data, file_is_yaml, matches)
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/transformer.py", line 151, in _do_transforms
    match.rule.transform(match, file, data)
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ansiblelint/rules/name.py", line 195, in transform
    isinstance(task["notify"], str)
               ~~~~^^^^^^^^^^
  File "/home/me/projects/ansible/opt/tf-ansible-WA5-pL_2-py3.11/lib/python3.11/site-packages/ruamel/yaml/comments.py", line 853, in __getitem__
    return ordereddict.__getitem__(self, key)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'notify'

@Qalthos
Copy link
Contributor

Qalthos commented Apr 17, 2024

Just faced the same issue but with a notify keyword.

That's actually #4093 instead, but thanks for the report

@Qalthos
Copy link
Contributor

Qalthos commented Apr 17, 2024

That really is the most minimal reproducer. Amazing.

What's going on here as best as I can figure is that the rule is getting confused, but only with a block in a second play. Anything less than that... two tasks in one play, only the second play has a block, plays in a different order, anything else, and the rule correctly identifies the location of the error. But with this specific organization of plays and tasks, the rule points to the task inside the block and not the block itself as the culprit, which does not in fact have a when keyword.

This hopefully shouldn't be too hard to fix, at least not once I've figured out why it's doing that.

@TamiTakamiya
Copy link

Sorry I have sent a few comments, which should have been added to #4093. Comments were deleted.

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

Successfully merging a pull request may close this issue.

5 participants