Preparing an environment for developing Ansible modules
You just need ansible-core installed to test the module. Modules can be written in any language, but most of the following guide is assuming you are using Python. Modules for inclusion in Ansible itself must be Python or Powershell.
One advantage of using Python or Powershell for your custom modules is being able to use the module_utils common code that does a lot of the heavy lifting for argument processing, logging and response writing, among other things.
It’s unfortunate that the languages for inclusion are limited to Python and Powershell, and I understand why, but why make this an error vs a warning?
There are collections that are writing modules in other languages because some platforms don’t come with Python (yet) and to ensure a users first experience with using Ansible on a particular platform, they may offer something like ping in a platforms available language, in my case that is REXX.
Which results in:
ERROR: Found 2 validate-modules issue(s) which need to be resolved:
ERROR: plugins/modules/zos_ping.rexx:0:0: invalid-extension: Official Ansible modules must have a .py extension for python modules or a .ps1 for powershell modules
ERROR: plugins/modules/zos_ping.rexx:0:0: python-syntax-error: Python SyntaxError while parsing module
I could create a ignore-2.xx.txt file but then have to justify the ignore entry. Any thoughts about removing this ansible-test error or reducing it to a warning?
(I moved this from Get Help to Project Discussions. Also pinging @mattclay.)
I think having this error by default is good for most collections, since 99% of the collections only have Python and/or PowerShell modules. But it would be great if it could be disabled via the ansible-test config file (ansible/test/lib/ansible_test/config/config.yml at devel · ansible/ansible · GitHub) for collections that do have modules in other languages. Having to list all modules in tests/sanity/ignore-*.txt is annoying.
(Making it possible to globally disable the missing-gplv3-license error for modules would also be great, this one is really annoying for collections whose modules use a difference license.)
The missing-gplv3-license error disablement would be great as well, we have over 20 modules we maintain those license ignore entries, and collectively, over 60 modules for our organization.
We don’t really have any current plans for extending ansible-test for more flexible collection testing at this time. The original reason that ansible-test became the standard for testing collections was largely because nothing else existed, so collections inherited the same rules as ansible-core.
Our goal going forward is basically to stop adding new testing functionality for collections to ansible-test, and move the ansible-test included with core back to only testing core. Which will require that we get another team on board with forking ansible-test to solely support collections, or to implement different tooling for the long term support of collections. In theory we have this agreement in place, but no timelines, work, discussions, or architecture have happened as of yet.
Thanks @sivel , understood, I will let the Ansible partners know that our ignore text entries will continue on for some time.
Just today I was looking back at ansible-test that came with 2.9, which at the time had 44 tests and the ‘latest’ has 32; I had thought this was a result of more being put into ansible-lint but your explanation summarizes it well.
How does ansible-lint fit into any of this in terms of focusing more on collections instead of ansible-test?