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

Ansible-review can't parse roles with dependices from custom modules #16

Open
strangeman opened this issue Nov 2, 2016 · 6 comments
Open

Comments

@strangeman
Copy link

Hi!

In my playbook, I use role spring-boot, which depends from role maven-download, which provides module maven_download.

Ansible-review fails with error:

Couldn't parse task at roles/spring-boot/tasks/extract_artifact.yml:17 (no action detected in task. This often indicates a misspelled module name, or incorrect module path.)
{ 'maven_download': 'group_id={{ item.group_id }} artifact_id={{ item.artifact_id }} version={{ item.artifact_version }} classifier=apidoc dest={{ doc_dest }}/{{ item.artifact_id }}.zip repository_url={{ maven_repo }} username={{ maven_repo_username }} password={{ maven_repo_password }}',
  'name': 'download {{ item.artifact_id }} java package',
  'register': 'download_result'}
@willthames
Copy link
Owner

Yeah, that's a difficult one. I'm really a little unsure as to better do this.

Currently the pragmatic way is to add module directories to the ANSIBLE_LIBRARY path. I know that's a rubbish solution, but (a) I believe that dependent roles is a recipe for disaster and (b) even if I didn't believe that, there's no code in ansible-review that does the dependency analysis, because it's hard, and because ansible-review is a file-based review tool (it can find a meta/main.yml so what you're asking isn't impossible, just unlikely in the absence of a useful PR)

@strangeman
Copy link
Author

strangeman commented Nov 2, 2016

add module directories to the ANSIBLE_LIBRARY path

Yeah, this workaround is acceptable for me. We use only 3 roles which provide custom modules, so it will be not hard.

BTW, ansible-lint and ansible-review are awesome tools, thanks a lot!

openstack-gerrit pushed a commit to openstack-infra/zuul-jobs that referenced this issue Mar 29, 2018
The 'linters' tox environment was not running on roles, it was only
running on playbooks. This change adds a command to the linters
environment to ensure all roles are linted.

Since these weren't being linted, there were some problems with them.
The first was a warning about usage of the shell module. Both of these
usages seemed appropriate, so this patch adds a skip_ansible_lint tag to
each task that was failing. The second is a warning "no action detected
in task" for zuul modules. This is due to the fact that the linter
cannot find the custom module. One option is to set the ANSIBLE_LIBRARY
path to point to the zuul ansible library directory[1], but the linter
virtualenv does not actually have zuul installed. Instead, we just
disable the linter for the failing tasks.

This also cleans up a comment in the tox file that was referring to a
nonexistent zuul job.

[1] willthames/ansible-review#16

Change-Id: Ie49da9a09733b623bb25c5a4c8aa07eacacf4b33
@ssbarnea
Copy link

Any plans to fix this? At least if we would have a config option inside .ansible-lint config file, we could use this one to avoid adding an extra environment variable which is extremely problematic for using the linter from other tools where ability to define environment variable may be very limited (gui apps/editors). The linter should be usable and controllable without having to hack environment variables.

@willthames
Copy link
Owner

willthames commented Jul 12, 2018

I'd definitely favourably consider a PR that implemented that idea @ssbarnea

@ewascent
Copy link

we also have the ansible.cfg file that does the same task as the environment variable (listing the libraries folder in my case)

@MaciejKucia
Copy link

Taking ansible.cfg into consideration would be fantastic.

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

No branches or pull requests

5 participants