incompatible with ansible-lint 4.3.5
finkelamein opened this issue · comments
using ansible-lint 4.3.5 causes an error:
An unexpected error with ansible, ansible-lint, linter-ansible-linting, atom, linter, and/or your playbook, has occurred.
You can skip specific rules or tags by adding them to your configuration file:
┌──────────────────────────────────────────────────────────────────────────────┐
│# .ansible-lint │
│warn_list: # or 'skip_list' to silence them completely │
│ - '206' # Variables should have spaces before and after: {{ var_name }} │
└──────────────────────────────────────────────────────────────────────────────┘
It seems the summary is now sent to stderr instead of stdout.
So I could guess this is due to a breaking change in how rule skips are handled, but could you share your package configuration and a minimal reproducible example?
linter-ansible-lint package is fully default
This will probably already trigger it:
- name: create backup user
user: name={{backup_user}} comment="User to store backups"
state="present" createhome="yes" home=/home/{{backup_user}}
tags:
- backup_server
difference in ansible-lint can be observed by:
$ pip install ansible-lint==4.3.5
$ ansible-lint roles/backup_server/tasks/main.yml > /dev/null
You can skip specific rules or tags by adding them to your configuration file:
┌──────────────────────────────────────────────────────────────────────────────┐
│# .ansible-lint │
│warn_list: # or 'skip_list' to silence them completely │
│ - '206' # Variables should have spaces before and after: {{ var_name }} │
└──────────────────────────────────────────────────────────────────────────────┘
$ pip install ansible-lint==4.3.4
$ ansible-lint roles/backup_server/tasks/main.yml > /dev/null
$
My guess is that Atom just errors out if there's any output on stderr
So it appears the pep8 parseable output functionality was broken somehow in 4.3.5. I will go file an issue.
That is not a bug in ansible-lint, but a wrong usage of the stderr. stderr is not used only for errors, but also for logging and any out-of-band messaging.
Failing if output is present on stderrr is a bug. I am aware that ansible-lint has lots of bugs, but that one is not one of them ;)
@finkelamein Maintaining the parseable output was declined, so I will commit work to circumvent this behavior as next priority. There are options in a dependency package to assist in the rare situations when a linter outputs non-errors to stderr, but the base assumption in the dependency packages for Atom Editor integrations is that linters do not adhere to that behavior.
@finkelamein Please read the linked ticket. The previous comment from @mschuchard is misleading. Parseable output is supported and will remain, is just that you need to be sure you read only stdout, as -p applies only to stdout, stderr being not really parseable, more of logging/informative format.
I understood that, I already implied that atom just errors when it get's anything on stderr.
I agree stuff on stderr shouldn't be the sole reason to throw an error, a non-zero exit code should do that.
I think @mschuchard is already planning to use a package in this extension to ignore stderr
There are options in a dependency package to assist in the rare situations when a linter outputs non-errors to stderr, but the base assumption in the dependency packages for Atom Editor integrations is that linters do not adhere to that behavior.
I agree stuff on stderr shouldn't be the sole reason to throw an error, a non-zero exit code should do that.
Actually, multiple linters including ansible-lint have non-zero exit codes as soon as one warning is emitted. Exit codes cannot be reliably used with linters as an indication of an error by the established standards, unless they are tied to the specific event encountered during execution (this is nice to have, but not common).
No worries about path forward; this will be resolved. I will update the issue when the fix is committed and pushed.
@ssbarnea Thank you for your initiative, but these integrations work via packages and interconnected APIs. I had to delete your suggestion as it was unrelated to the functionality of Atom Editor and the packages providing this functionality to consume linters, and did not want @finkelamein or others to be misled.