# Ansible-lint resolving symlinks to their destinations? **URL:** \ **Category:** Get Help\ **Tags:** ansible-lint\ **Created:** [February 20, 2025, 10:16am UTC](https://forum.ansible.com/t/ansible-lint-resolving-symlinks-to-their-destinations/40388 "2025-02-20T10:16:17Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![noonedeadpunk](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/noonedeadpunk/32/7605_2.png) [@noonedeadpunk](https://forum.ansible.com/u/noonedeadpunk)\ **Post date:** [February 20, 2025, 10:16am UTC](https://forum.ansible.com/t/ansible-lint-resolving-symlinks-to-their-destinations/40388/1 "2025-02-20T10:16:17Z")
I’ve started seeing a weird behavior with ansible-lint quite recently. Specifically, that it seems it started to resolving symlinks to their destination. While it can be fine in most cases, it is very confusing in CI, where instead of installing role as it should be installed, we symlink it from CI-prepared directory to DEFAULT\_ROLES\_PATH An example of that is [Zuul](https://zuul.opendev.org/t/openstack/build/7bfe965e949343638c6b06fe5bf45a91) We make a symlink from /home/zuul/src/opendev.org/openstack/ansible-role-httpd/ to /etc/ansible/roles/httpd/ (as we expect users to have role installed under it’s proper name). Then, our example playbook tries to be quite abstract, ie: ```auto --- - name: Installing Apache Web Server hosts: httpd roles: - role: "{{ playbook_dir | dirname | basename }}" ``` So while we run `ansible-lint /etc/ansible/roles/httpd/examples/playbook.yml` it actually seems to launch “original” location: `/home/zuul/src/opendev.org/openstack/ansible-role-httpd/examples/playbook.yml` Full output is like this: ```auto + /opt/ansible-runtime/bin/ansible-lint /etc/ansible/roles/httpd/examples/playbook.yml -c /home/zuul/src/opendev.org/openstack/openstack-ansible/.ansible-lint WARNING: PATH altered to include /opt/ansible-runtime/bin, /opt/ansible-runtime/bin :: This is usually a sign of broken local setup, which can cause unexpected behaviors. [DEPRECATION WARNING]: DEFAULT_GATHER_SUBSET option, the module_defaults keyword is a more generic version and can apply to all calls to the M(ansible.builtin.gather_facts) or M(ansible.builtin.setup) actions, use module_defaults instead. This feature will be removed from ansible-core in version 2.18. Deprecation warnings can be disabled by setting deprecation_warnings=False in ansible.cfg. WARNING Listing 1 violation(s) that are fatal syntax-check[specific]: the role 'ansible-role-httpd' was not found in /home/zuul/src/opendev.org/openstack/ansible-role-httpd/examples/roles:/root/.cache/ansible-compat/8cbc9d/roles:/etc/ansible/roles:/etc/ansible/roles/ceph-ansible/roles:/home/zuul/src/opendev.org/openstack/ansible-role-httpd/examples /home/zuul/src/opendev.org/openstack/ansible-role-httpd/examples/playbook.yml:5:7 # Rule Violation Summary 1 syntax-check profile:min tags:core,unskippable Failed: 1 failure(s), 0 warning(s) on 1 files. ``` Any ideas on how to prevent this from happening? ---
**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\ **Post date:** [February 20, 2025, 11:52am UTC](https://forum.ansible.com/t/ansible-lint-resolving-symlinks-to-their-destinations/40388/2 "2025-02-20T11:52:16Z")
Is this the same issue as this `molecule` one? > > > \### Prerequisites > > \- \[x\] This was not already reported in the past (duplicate ch…eck) > \- \[x\] It does reproduce it with code from main branch (latest unreleased version) > \- \[x\] I include a minimal example for reproducing the bug > \- \[x\] The bug is not trivial, as for those a direct pull-request is preferred > \- \[x\] Running \`pip check\` does not report any conflicts > \- \[x\] I was able to reproduce the issue on a different machine > \- \[x\] The issue is not specific to any driver other than 'default' one > > \### Environment > > I have tested in multiple environments, the following two are where the issue arises: > > 1. Main branch > \`\`\` > molecule 25.2.1.dev2 using python 3.11 > ansible:2.17.8 > gce:23.7.0 from molecule\_plugins requiring collections: google.cloud\>=1.0.2 community.crypto\>=1.8.0 > docker:23.7.0 from molecule\_plugins requiring collections: community.docker\>=3.10.2 ansible.posix\>=1.4.0 > vagrant:23.7.0 from molecule\_plugins > default:25.2.1.dev2 from molecule > azure:23.7.0 from molecule\_plugins > ec2:23.7.0 from molecule\_plugins > openstack:23.7.0 from molecule\_plugins requiring collections: openstack.cloud\>=2.1.0 > podman:23.7.0 from molecule\_plugins requiring collections: containers.podman\>=1.7.0 ansible.posix\>=1.3.0 > containers:23.7.0 from molecule\_plugins requiring collections: ansible.posix\>=1.3.0 community.docker\>=1.9.1 containers.podman\>=1.8.1 > \`\`\` > > 2. Version 25.2.0 > \`\`\` > molecule 25.2.0 using python 3.11 > ansible:2.17.8 > openstack:23.7.0 from molecule\_plugins requiring collections: openstack.cloud\>=2.1.0 > gce:23.7.0 from molecule\_plugins requiring collections: google.cloud\>=1.0.2 community.crypto\>=1.8.0 > ec2:23.7.0 from molecule\_plugins > docker:23.7.0 from molecule\_plugins requiring collections: community.docker\>=3.10.2 ansible.posix\>=1.4.0 > vagrant:23.7.0 from molecule\_plugins > podman:23.7.0 from molecule\_plugins requiring collections: containers.podman\>=1.7.0 ansible.posix\>=1.3.0 > azure:23.7.0 from molecule\_plugins > containers:23.7.0 from molecule\_plugins requiring collections: ansible.posix\>=1.3.0 community.docker\>=1.9.1 containers.podman\>=1.8.1 > default:25.2.0 from molecule > \`\`\` > > Using mac osx 14.7.2. > > \### What happened > > Running \`molecule test\` in a specific ansible role directory fails using molecule version 25. The exact same command with molecule version 24.12.0, runs successfully. > > \### Reproducing example > > \`\`\`yml > Not available. > \`\`\` Does setting `ANSIBLE_ROLES_PATH` to something like this solve the issue? ````auto /home/zuul/src/opendev.org/openstack:/root/.cache/ansible-compat/8cbc9d/roles:/etc/ansible/roles:/etc/ansible/roles/ceph-ansible/roles``` ```` ---
**Author:** ![noonedeadpunk](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/noonedeadpunk/32/7605_2.png) [@noonedeadpunk](https://forum.ansible.com/u/noonedeadpunk)\ **Post date:** [February 20, 2025, 12:23pm UTC](https://forum.ansible.com/t/ansible-lint-resolving-symlinks-to-their-destinations/40388/3 "2025-02-20T12:23:43Z")
Yeah, I think that the bug report mentioned is related. I think we’ve started observing the issue between Jan 14 and Feb 17. And sure, adjusting `ANSIBLE_ROLES_PATH` would sort it out. But the point is kind of to set the CI in a way that most consumers will use roles as well, so we’d love to avoid this workaround. Another workaround would be in our case to leave an example playbook alone, and supply molecule a different converge file. As this approach with `role: "{{ playbook_dir | dirname | basename }}"` was to satisfy both molecule and ansible-lint which we execute separately. ---
**Author:** ![ssbarnea](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ssbarnea/32/4923_2.png) [@ssbarnea](https://forum.ansible.com/u/ssbarnea)\ **Post date:** [March 20, 2025, 2:12pm UTC](https://forum.ansible.com/t/ansible-lint-resolving-symlinks-to-their-destinations/40388/4 "2025-03-20T14:12:54Z")
At this moment there are no plans to change this because only by resolving the paths we can get a normalized file path that we can compare with others and avoid duplicates. Also there are tools that fail to resolve symlinked paths so resolving them gives a better experience. If the very long path annoys you, you can probably ensure that your preinstalled dependencies are copied inside the current project because in this case ansible-lint will report paths relative to project directory. ---
**Author:** ![noonedeadpunk](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/noonedeadpunk/32/7605_2.png) [@noonedeadpunk](https://forum.ansible.com/u/noonedeadpunk)\ **Post date:** [March 20, 2025, 3:03pm UTC](https://forum.ansible.com/t/ansible-lint-resolving-symlinks-to-their-destinations/40388/5 "2025-03-20T15:03:57Z")
It is slightly more complicated, unfortunately Zuul does prepare for us repositories in /home/user/zuul/repo/ansible-role-$role\_name So what we are doing, is symlinking from that path to `ANSIBLE_ROLES_PATH` with renaming from `ansible-role-$role_name` to expected `$role_name` Thus eventually you would get a completely different role name depending if you execute molecule or ansible. And then also a difference if you run with zuul or locally, where installation will be handled by galaxy. With that such approach allows to test current role/collection dependencies as well, as zuul can include other patches and speculatively merge them in CI jobs… I think we’ve found a workaround this somehow for now though, but it’s just a bit unfortunate that behavior is different.