No support for yamllint yet?

[ChristianCiach]

The README states:

Display violations identified by ansible-lint, ansible own syntax check and yamllint inside problems tab.

The VSCode extension description states:

Ansible YAML schema verification, auto-complete, highlight problems reported by ansible-lint or yamllint and vault encryption and decryption.

But I cannot find any support for yamllint. In fact, when I search this repo for the word yamllint, the only matches are in text files.

Is this feature yet to come?

Edit: I know this sounds like a "feature request", but I've posted this as a "bug" because the current project descriptions advertise a feature that may not be there. In this case, I think this is a "bug" in the descriptions.

[ChristianCiach]

It looks like ansible-lint is supposed to call yamllint using the YamllintRule, but this doesn't seem to work for me, or at the very least it doesn't pick up my .yamllint file in my workspace root.

[ssbarnea]

If you have yamllint installed, it will include problems reported by it too. The trick is that yamllint must be installed inside the same python venv as ansible-lint itself. Yamllint is not called directly by the extension, it is called by ansible-lint itself while it is looking at all the files from the repo.

I can assure you that it works as I am using it daily.

What can make this harder to debug is the fact that ansible-lint does silently ignores absence of yamllint. I am almost sure that is what you encounter.

[ChristianCiach]

Well, I can't even make ansible-lint to incorporate yamllint when using ansible-lint directly on the terminal, so this doesn't seem to be an issue with this extension.

Thank you for your quick reply though!

I will close this issue for now.

[ChristianCiach]

The issue was that we were still using ansible-lint 4.*, which doesn't include the YamllintRule.

But after updating ansible-lint to 5.0.12, I just can't get this extension to work at all.

> ansible-lint --v
ansible-lint 5.0.12 using ansible 2.11.2

ansible-lint works nicely on the console, but the extension is completely non-functional and just doesn't show any error messages. When I downgrade ansible-lint to version 4, it immediately starts working again.

I have absolute no idea how to debug this. It would be nice if this extension could print some errors if something is wrong instead of just failing silently. I am trying for over an hour now.

[ChristianCiach]

The issue is that ansible-lint, when invoked by this extension, doesn't find my ansible installation.

But this can only be seen when debugging this extension and opening the "debug console". For some reason, this error never finds its way into the catch (error)-block and just gets swallowed. I am not a JavaScript programmer and debugging JS seems to be a nightmare. Whenever i try to step into something to see what happens, suddenly the debugger jumps into a completely unrelated closure.

It's a bummer that the extension doesn't inherit the PATH of the currently active environment. We aren't using Venv, but conda environments instead.

If this extension can only be used by putting symlinks and stuff into the global PATH, there is no way I can make my coworkers use this extension. What a bummer.

[ChristianCiach]

I have a suggestion: Maybe you could allow us to define a custom PATH as a setting and fall back to process.env if undefined. Or maybe let us define an additional PATH that will be prepended to the PATH of process.env...

I got this to work by hacking may own env-parameter into the code in validationProvider.ts:

var coolenv = { PATH: '/data/ssd/christianc/emsconda/envs/core-platform-ng/bin'}
let options = (vscode.workspace.workspaceFolders && vscode.workspace.workspaceFolders[0]) ? { cwd: vscode.workspace.workspaceFolders[0].uri.fsPath, env: coolenv } : undefined;

(Again, please keep in mind, I don't know TypeScript or JavaScript at all.).

So, the extension can find the ansible executable now. But now it can't parse a single line that ansible-lint outputs.

Validating /data/ssd/christianc/ansible/core-platform-ng/play.galera-grants.yaml
Failed to recognize linter output line: play.galera-grants.yaml:6: yaml string value is not quoted with single quotes (quoted-strings)
Failed to recognize linter output line: play.galera-grants.yaml:7: yaml string value is not quoted with single quotes (quoted-strings)
Failed to recognize linter output line: play.galera-grants.yaml:9: unnamed-task All tasks should be named
Failed to recognize linter output line: play.galera-grants.yaml:16: yaml string value is not quoted with single quotes (quoted-strings)
Failed to recognize linter output line: play.galera-grants.yaml:17: yaml string value is not quoted with single quotes (quoted-strings)
Failed to recognize linter output line: play.galera-grants.yaml:18: yaml string value is not quoted with single quotes (quoted-strings)

I guess the regex just doesn't match the actual output.

[ChristianCiach]

It works now! The parse issue I've just described happened because I still had parseable: true in my .ansible-lint from my previous desperate attempts to debug this issue. After removing this setting, the extension can now parse the output.

So, this just leaves the PATH issue. What do you think about my suggestion to make this configurable? If we could configure the PATH (as suggested, maybe as an addition to the default PATH, but please prepend the configured PATH to the global one) per-workspace, I think that would be a nice solution. Should I open another issue for this? @ssbarnea

[ssbarnea]

These findings are really useful as they should help us improve it. Configured output in settings should not affect the tool. Still, at this moment we do not even check the version of the linter, but we should, and have a popup msg when we detect a problem.