CfgMgmtCamp 2026 discussion (9/12): Deprecations and ansible-test

As a collection developer/maintainer

Deprecations and ansible-test

Latest developments

It seems that with better warning/deprecation control there might be improvements coming here as well.
Right now it’s too early to tell.

Original text

Right now, ansible-test integration swallows all deprecation messages.

If ansible-core deprecates something, looking at new deprecation warnings in integration tests should help finding this out. Unfortunately there’s no information on deprecations there.

The result is that maintainers don’t notice deprecations unless they happen to use the modules/plugins outside tests. Especially for collections such as community.general, where many things aren’t actively maintained, the result is that either eventually a user creates an issue about a deprecation, or (worse) eventually something suddenly and unexpectedly breaks since a deprecated feature was finally removed.

This makes it a bad developer experience, and often also a bad user experience as users see these deprecation messages that are aimed at developers. Deprecation messages you cannot really do something about are very frustrating.

It would be much better if deprecation warnings would not be eaten, but reported. It would be even better if you could explicitly say for a task which (deprecation) warnings are OK, and which ones should result in a failure. This requires being able to identify (deprecation) warnings though - see “Speaking about deprecations”.

2 Likes

Surfacing deprecations and probably even warnings through ansible-test is something we’ve been talking about for a while. It helps the core team as well, since there are thousands of tasks in integration tests it’s often hard for us to find them as well. I don’t know what it would look like or any timeframe, but I’m generally in agreement with the sentiment of this.

4 Likes