Linter produces unresolved module errors for collections

[ansiblejunky]

Summary

Using a typical Ansible Project repository with collections/requirements.yml listing dependencies for Ansible Collections, ansible-lint produces a ton of couldn't resolve module/action errors for each task that uses a module inside an Ansible Collection. The typical solution is to run ansible-galaxy collection install -r collections/requirements.yml to get the collections installed locally so that ansible-lint can find them and not report errors.

However, as a typical Ansible developer maintaining this repository I only have this option if all of my collections can be pulled from external (internet) sources such as Galaxy. If some of these collections are only found from Certified Collections (only from RH site) then I will need to additionally provide a token. And since I'm just a typical Ansible developer (employee of an organization, and not administrator of AAP, etc), then I don't have access to a token string (generated from RH console site). So this puts me into a bind, where I cannot run ansible-lint cleanly anymore because I cannot download those Certified Collections. We know of course, if I want to run/test my playbook I can definitely run ansible-navigator using a prepared/published ExecEnv image that contains all the Collections I need. That is, assuming I'm not developing for the first time against this needed Certified Collection.

So what is the best way to handle this situation? The scenario simplifies the problem with 1 repository, but in reality we're talking about a bunch of Ansible developers at a company all doing this.

Taking this to another level, when ansible-lint is setup as a Github Action, it's running inside a container. We can provide the requirements.yml as an argument, but again how can we run ansible-lint when some of those collections are Certified Collections? We need to provide a token to get these. And it's not reasonable to have that token stored somewhere in the repository, since there may be a ton of repositories with this problem.

I know with ansible-lint you have the option of adding mocked modules in the config file, but this is not reasonable to add every single module from these Collections.

Issue Type

• Bug Report

OS / ENVIRONMENT

ansible-lint --version
ansible-lint 25.1.2 using ansible-core:2.16.5 ansible-compat:25.1.2 ruamel-yaml:0.18.5 ruamel-yaml-clib:0.2.7

RHEL 9.x

• ansible installation method: pip
• ansible-lint installation method: pip

STEPS TO REPRODUCE

Create a typical Ansible Project repository with following structure:

playbooks/
inventory/
roles/
collections/
    requirements.yml
files/
plugins/

Be sure to have a Certified Collection listed in the requirements.yml such as:

---
collections:
  - name: redhat.rhel_idm

Create the playbook to use a module from the collection:

---
- hosts: all
  become: false
  gather_facts: false
  
  tasks:
    # Ensure host is present without DNS
    - redhat.rhel_idm.ipahost:
        ipaadmin_password: SomeADMINpassword
        name: host02.example.com
        description: Example host
        force: yes

Run ansible-lint and it complains about ansible-galaxy, but inside VSCode it shows a red-line on the collection module referenced in the task in the playbook saying couldn't resolve module/action.

Desired Behavior

ansible-lint is able to check code quality without hitting into these errors, which prevent getting a "pass" from the linter.
Perhaps informing ansible-lint to accept some collections and related modules? Maybe adding a # noqa on the collection listed in the requirements.yml? Not sure what the solution might be here, but just an idea.

Actual Behavior

ansible-lint produces too many resolve errors for both local development and remote operations (github action).

[ssbarnea]

You need to find a way to install these dependencies. Without them running the linter will not give reliable results. There are multiple ways you can do this, including using submodules.

If you cannot rely on ansible itself to find and install these dependencies you will have to script their installation before you run the linter. This will likely rule out some ways of calling the linter, for example using it with pre-commit.ci you will not be able to install them but you can skip running it under pre-commit.ci (which does not give network access) and run pre-commit tool yourself using github actions.

I would not rely on mocking as we might even decide to remove that feature in the future. It was a temporary measure. The reality is that without resolving the dependencies, you cannot really analyze the code.

[alisonlhart]

Closing as this is not a bug.