Undeprecate numeric rule tags #1447
Conversation
The reason behind the undeprecation is fairly simple: right now, it is impossible to create a playbook that uses tags that will not trigger any warnings on ansible-lint 4 or 5. If we use numeric tags, ansible-lint >= 5 will complain. If we use more descriptive tags, introduced in ansible-lint 5.0.0, ansible-lint < 4 will complain about the errors we want to ignore. This is especially important for collection authors that publish their work on Ansible Galaxy. On each import, Ansible Galaxy runs ansible-lint 4 over all of the roles. Those developers are, if they want to have a clean import, forced to use an older version of ansible lint, or have ansible-lint >= 5 complain about numeric tags.
tadeboro
force-pushed
the
undeprecate-numeric-tags
branch
from
4c885cc
to
cd50e43
Compare
|
Delaying the deprecation until later in the 5.x release cycle (or even until 6, depending on how fast that happens) sounds like a good idea! |
|
I am ok with it but first I want to see some feedback from the galaxy team members. I do not ever remember when it was last time when someone from the galaxy team made a pull request or at least gave feedback on irc or issue tracker. AFAIK there is no proof that any galaxy engineer is watching what we do. Even an ok or not from time to time would be ok. In fact the version of the linter used by galaxy server is not even documented and we do not have any indication on what is needed to upgrade it. Without this, I struggle to find motivation to add extra effort/hacks for unsupportive consumers. How about adding an option to silence the deprecation warning instead? If we do not display anything we cannot drive people to update the code. |
|
Maybe I emphasized the Ansible Galaxy aspect of this problem a bit too much because this is how I discovered that my "port to ansible-lint 5" effort has some unintended side-effects. But the problem is more general. Migrating between two major versions of a tool is already stressful enough. And not being able to have content that produces a clean run on both versions of the tool only increases the stress level because now migration is an all-or-nothing thing. |
| k, | ||
| v, | ||
| ) | ||
| # Do not deprecate the odl tags just yet. Why? Because it is not currently feasible |
There was a problem hiding this comment.
| # Do not deprecate the odl tags just yet. Why? Because it is not currently feasible | |
| # Do not deprecate the old tags just yet. Why? Because it is not currently feasible |
| # Do not deprecate the odl tags just yet. Why? Because it is not currently feasible | ||
| # to migrate old tags to new tags. There are a lot of things out there that still | ||
| # use ansible-lint 4 (for example, Ansible Galaxy and Automation Hub imports). If we | ||
| # replace the odl tags, those tools will report warnings. If we do not replace them, |
There was a problem hiding this comment.
@felixfontein You missed this:)
| # replace the odl tags, those tools will report warnings. If we do not replace them, | |
| # replace the old tags, those tools will report warnings. If we do not replace them, |
|
@tadeboro Can you please rebase so i can merge it? Next time create a feature branch so we can edit it (you have this power). |
|
Closed in favour of #1452 as I cannot rebase this one. |
The reason behind the undeprecation is fairly simple: right now, it is impossible to create a playbook that uses tags that will not trigger any warnings on ansible-lint 4 or 5.
If we use numeric tags, ansible-lint >= 5 will complain. If we use more descriptive tags, introduced in ansible-lint 5.0.0, ansible-lint
< 4 will complain about the errors we want to ignore.
This is especially important for collection authors that publish their work on Ansible Galaxy. On each import, Ansible Galaxy runs
ansible-lint 4 over all of the roles. Those developers are, if they want to have a clean import, forced to use an older version of ansible lint, or have ansible-lint >= 5 complain about numeric tags.