search

ansible / ansible-lint

ansible-lint checks playbooks for practices and behavior that could potentially be improved and can fix some of the most common ones for you
https://ansible.readthedocs.io/projects/lint/
GNU General Public License v3.0
3.5k stars 664 forks source link

ansible-lint is not consistent with Galaxy importer checks #4032

Open falon opened 9 months ago

falon commented 9 months ago
Summary

I run ansible-lint before publishing a collection into my Galaxy-NG. Even if ansible-lint doesn't detect errors or warnings, the publish process shows warning about dependencies.

ansible-lint should warn me if Galaxy-NG has something else to claim.

Issue Type
OS / ENVIRONMENT
# ansible-lint --version
ansible-lint 24.2.0 using ansible-core:2.16.2 ansible-compat:4.1.11 ruamel-yaml:0.18.5 ruamel-yaml-clib:0.2.8
# Galaxy-NG 
Server version
    [4.9.1 ]
Pulp Ansible Version
    [0.20.3 ]
Pulp Container Version
    [2.15.4 ]
Pulp Core Version
    [3.28.23 ]
Galaxy Importer
    [0.4.20]
STEPS TO REPRODUCE

Let suppose I developed a collection with a playbook that use an external role: playbooks/myOS.yml:

[...]
roles:
    - arillso.logrotate

Also, let suppose the collection has dependecies in galaxy.yml:

[...]
dependencies:
   "community.general": ">=8.1.0"
   "community.docker": ">=3.4.11"

In my local environment I have installed all standalone roles and collections required. Then:

# cd /path/to/collection
# ansible-lint
Passed: 0 failure(s), 0 warning(s) on 149 files. Last profile that met the validation criteria was 'production'.

# ansible-galaxy collection build

This is all fine. But when I try to publish on Galaxy-NG I see new unexpected warnings:

# ansible-galaxy collection publish --server myserver <collection_name>-1.0.0.tar.gz
[...]
[WARNING]: Galaxy import warning message: playbooks/myOS.yml:300:7: syntax-check[specific]: the role 'arillso.logrotate' was not found 
[WARNING]: Galaxy import warning message: roles/dnf_automatic_notifier/tasks/main.yml:9:3: syntax-check[specific]: couldn't resolve module/action 'community.general.ini_file'. This often indicates a misspelling, missing collection, or incorrect module path.
[WARNING]: Galaxy import warning message: roles/hostnamectl/tasks/main.yml:4:3: syntax-check[specific]: couldn't resolve module/action 'community.docker.current_container_facts'. This often indicates a misspelling, missing collection, or incorrect module
path.
[WARNING]: Galaxy import warning message: roles/journald/tasks/main.yml:12:3: syntax-check[specific]: couldn't resolve module/action 'community.general.ini_file'. This often indicates a misspelling, missing collection, or incorrect module path.
[WARNING]: Galaxy import warning message: roles/rhsub/tasks/main.yml:14:3: syntax-check[specific]: couldn't resolve module/action 'community.general.redhat_subscription'. This often indicates a misspelling, missing collection, or incorrect module path.

I can't fix these warnings. I tried to sync remote required collections in Galaxy-NG, but it has no effect.

Desired Behavior
# ansible-galaxy collection publish --server myserver <collection_name>-1.0.0.tar.gz
Publishing collection artifact '/root/.ansible/collections/ansible_collections/...
Collection has been published to the Galaxy server ...
Waiting until Galaxy import task ... has completed
Collection has been successfully published and imported to the Galaxy server ...
Actual Behavior
Publishing collection artifact ...
Collection has been published to the Galaxy server ...
Waiting until Galaxy import task .... has completed
[WARNING]: Galaxy import warning message: playbooks/myOS.yml:300:7: syntax-check[specific]: the role 'arillso.logrotate' was not found in...
[WARNING]: Galaxy import warning message: roles/dnf_automatic_notifier/tasks/main.yml:9:3: syntax-check[specific]: couldn't resolve module/action 'community.general.ini_file'. This often indicates a misspelling, missing collection, or incorrect module path.
[WARNING]: Galaxy import warning message: roles/hostnamectl/tasks/main.yml:4:3: syntax-check[specific]: couldn't resolve module/action 'community.docker.current_container_facts'. This often indicates a misspelling, missing collection, or incorrect module
path.
[WARNING]: Galaxy import warning message: roles/journald/tasks/main.yml:12:3: syntax-check[specific]: couldn't resolve module/action 'community.general.ini_file'. This often indicates a misspelling, missing collection, or incorrect module path.
[WARNING]: Galaxy import warning message: roles/rhsub/tasks/main.yml:14:3: syntax-check[specific]: couldn't resolve module/action 'community.general.redhat_subscription'. This often indicates a misspelling, missing collection, or incorrect module path.
Collection has been successfully published and imported to the Galaxy server ...

See also at the forum thread.

Blocked-By: https://issues.redhat.com/browse/AAH-3375 Related: https://github.com/ansible/galaxy-importer/pull/287

felixfontein commented 9 months ago

The Galaxy importer does not install dependencies before extracing docs or running ansible-lint. This causes a lot of errors/warnings that shouldn't be there.

Ref: https://forum.ansible.com/t/galaxy-importer-collection-dependency-handling/3496 (unfortunately there's no reaction from the Galaxy team...)

ssbarnea commented 9 months ago

@alisonlhart Maybe you do know more about the subject? Clearly this does not seem as an issue with the linter itself.

alisonlhart commented 9 months ago

@ssbarnea I wonder if this will be solved by upgrading the ansible-lint dependency. If not, IMO this is definitely something worth opening an issue for on galaxy-importer, especially when seeing the similar docs issue related to dependencies.

ssbarnea commented 2 months ago

I would like to repurpose this bug into a feature: add a rule that ensures that galaxy-importer passes for current collection.

It might sound a little bit recursive but I think we can find a way to avoid recursivity.

The main benefit here is that it reduces the number of checks a content developer needs to perform, as linting will also ensure that collection builds and it does not include unexpected files in that archive.

See https://github.com/ansible/event-driven-ansible/pull/291/files to get an idea about what extra checks were needed, which could easily be included in ansible lint.

audgirka commented 2 months ago

Related:

minsis commented 1 week ago

I started a discussion before finding some of these issues. So what its worth I've started one: https://github.com/ansible/ansible-lint/discussions/4404