I have a bunch of playbooks which usually are triggered by an API. So any warning about deprecated modules are hidden for me.
Usually, I read the changelog when updating a collection. But sometimes a miss a deprecated module. Is where a way to find any deprecated module ansible-lint or something else?
What I’ve found so far is, that ansible-lint knows only 20 or so deprecated modules, which are hardcoded.
I think a linter usually checks very static things, like the type of indentation (spaces vs tabs) or if there are spaces before and after the = in a variable assignment.
So I’m not sure if ansible-lint is the right tool to implement this, because what you’re trying to achieve is more dynamic in nature: It depends on the collections your currently using.
I might be completely wrong about this, and ansible-lint would be the right tool to check this. But I don’t know how to do it. Anyway, whether I’m right or wrong I think this is a very good question! I guess a solution to this problem would be helpful for a lot of people.
Just to make this clear: I guess you want to run this check automatically in some kind of CI pipeline, right? And this would inform you about deprecated modules… or how do you want to be informed? I guess this information would help others to suggest a solution.
CI/CD would be nice, when some deprecated module has been found, the pipeline should raise an error.
We’re using renovate to update the modules, so this would be triggered when renovate creates a new merge request.
since you run them automated, can’t you also automate checking the output for DEPRECATED and sending a message if so? I assume you already have the same for errors, it should not be hard to include warnings.
ansible-lint has a static list of deprecated modules that it will check against, so it could be run in CI/CD to catch those. It doesn’t dynamically catch newly deprecated modules, and there’s no way to add to that list via config. So that list would need to be updated via PR’s. If there’s a programmatic way to detect deprecations, someone needs to make a PR for it for ansible-lint.
On the other hand, there is also ansible-policy. It has the same problem as ansible-lint in that it would only be able to check a static list of deprecated modules, but you as the end-user can create and maintain a deprecation policy definition. Then you could run ansible-policy in your CI/CD pipeline, and it would throw policy violations for any deprecated code detected that you have added to the list.
I’m wondering why ansible-lint only has a static list of deprecated things, since it is very easy to read the routing information for all collections and use that to figure out what’s deprecated (you’d have to do some routing yourself, but that’s also pretty simple). (I know since antsibull-docs is basically doing that to figure out what is deprecated, and to create redirection stubs 
)
It could be a solution, but this has some problems:
deprecated only means they will be removed in the future, it does not normally require immediate action, it is just a warning that this module/plugin will go away, not that it is failing right now.
Ansible Lint does follow the plugin routing defined in the collection meta/runtime.yml, but I believe it does this only when you use the autofix (--fix) functionality. It will follow them and correct each task module FQCN. Seen this behaviour very recently with the dellemc.os10 collection.
When searching the ansible-lint repo for “deprecat*”, the only thing I noticed was src/ansiblelint/rules/deprecated_module, which only seems to have a static list it uses for reference.
Obviously there could be logic defined elsewhere, but I’m not sure where it would be.
simplest change, logic goes there and generates that list by using ansible-doc for installed plugins
That’s missing some parts, since redirects can also be deprecated (which isn’t part of the documentation); and it doesn’t really work for other things than actions, since you’d have to do the routing manually.
loading via the redirect will give you a deprecation message, that can also be captured
also, I would go farther, ‘deprecated plugin’.
This might not be the answer you are looking for but I have been thinking about this 
The upcoming ansible-core 2.19 changes a lot of things, including clearer exceptions and deprecations. For example:
TASK [smoke-tests : Add dynamically templated labels to this playbook] ****************************************************************************************************************************************************************************************
[DEPRECATION WARNING]: Jinja constant strings should not contain embedded templates. This feature will be removed in version 2.23.
Origin: /home/user/dev/sandbox/ara/ara/tests/integration/roles/smoke-tests/tasks/ara-ops.yaml:194:9
192 state: present
193 labels:
194 - "git:{{ lookup('pipe', 'git -C {{ playbook_dir }} rev-parse HEAD') }}"
^ column 9
[DEPRECATION WARNING]: Top-level facts are deprecated, use `ansible_facts` instead. This feature will be removed in version 2.22.
Origin: /home/user/dev/sandbox/ara/ara/tests/integration/roles/smoke-tests/tasks/ara-ops.yaml:195:9
193 labels:
194 - "git:{{ lookup('pipe', 'git -C {{ playbook_dir }} rev-parse HEAD') }}"
195 - "os:{{ ansible_distribution }}-{{ ansible_distribution_version }}"
^ column 9
If you wanted to capture these exceptions and deprecations programmatically, it turns out that ara will record them:
This requires running the playbook (with 2.19) vs running ansible-lint before running the playbook, but it’s something.
ara doesn’t do anything special with exceptions or deprecations (yet) but the data would be available via API 
2.19 is still in pre-release for a while, but it is available for testing.
