Open mattboston opened 1 year ago
The problem seems to either 1) in the salt-lint or 2) in the way that this plugin is calling salt-lint.
This plugin feeds salt-lint the source file through stdout/stdin redirection. This allows the plugin to feed an unsaved file to salt-lint and get the response back.
Unfortunately this cases the salt-lint
program to ignore all .salt-lint
config (as of version 0.9.2). You can replicate this on the command line fairly easily.
cd $project/pillar/
cat file.sls | salt-lint
It seems that salt-lint ignores the config file when reading the input from stdin, even if the config file is explicitly set like this:
cat file.sls | salt-lint -c $PWD/.salt-lint
One work-around may be allowing the user to specify CLI arguments to salt-lint and passing in -x SKIOP_LIST
, however this is cumbersome especially in collaborative environments.
Another work-around might be to write a temporary-file, run salt-lint, and then clean the temporary file up.
Regardless, I think starting a discussion with the upstream project is probably worth while
I think I figured out my issue, anyway. My .salt-lint
configuration file was based on file-names. And of course when we read from stdin, the filename is a temporary file.
---
rules:
204:
# Ignore long lines in pillar/users/init.sls
ignore: init.sls
@mattboston - do you use file-specific ignores like this?
@roaldnefs - if salt-lint
had a command line argument like --stdin-filename
or --tmp-filename foo.sls
that would tell salt-lint what filename to use for the purposes of interpreting the config file, would you make use of it in this vscode plugin?
Hi @jamesharr 👋🏻 ,
Thanks for your report! And I'm happy to see you seem to have resolved it already. We currently don't have time to super actively develop both salt-lint
and its vscode extension, so it could possibly take us a while to get around fixing it.
Though, your conclusion is correct in that salt-lint
is being fed temporary files in order to perform linting. Do keep in mind that you are able to append # noqa 204
to the end of the line that is too long. Though, I reckon that may not be a very suitable solution. We are still working on a method where you could add a # noqa
above a salt state, and the configured rule(s) will be ignored for the entire state.
Sorry for the inconvenience.
I understand, and I appreciate the work you've done. We're you thinking of supporting file-wide noqa settings in the upstream salt-lint, or doing it entirely in the vscode plugin?
My thought was primarily to let the plugin communicate the real name of the file to the CLI tool (and augment salt-lint so it can accept that information). If you have a preferred way of doing this, I can take a stab at a PR in upstream salt-lint as well as this plug-in (though I'm not a typescript person)
I upgraded to salt-lint v0.9.2, and have the latest vscode plugin, but I still have an issue. Below is my .salt-lint file in the top of my project folder. The main thing that I don't want to see is 204 long lines. The rest of what salt-lint reports is fine
---
exclude_paths: []
rules: {}
skip_list:
# Using `salt-lint` for linting other files as well, such as Ninja macros/templates
- 204 # Lines should be no longer than 160 chars
tags: []
verbosity: 1
Here's my simplified directory structure. I have a separate vscode project for the salt states and pillar, so the .salt-lint file is in the top of the file structure for each project.
salt/
├─ roles/
│ ├─ webserver/
│ │ ├─ init.sls
│ ├─ database/
│ │ ├─ init.sls
├─ top.sls
├─ .salt-lint
pillar/
├─ top.sls
├─ .salt-lint
├─ webserver.sls
├─ database.sls
When I was reading the salt-lint
code, it would only pick up .salt-lint
from the current working directory (PWD) and not any parent directories. This plugin uses the PWD of the file its analyzing.
For example, when linting salt/roles/webserver/init.sls
salt/roles/webserver
.salt-lint
file that salt-lint
will look for is salt/roles/webserver/.salt-lint
When you run salt-lint
on the CLI, you likely just run it from salt/
or pillar/
, so it picks up the config.
It would be nice if the extension could read a .salt-lint config file from the following locations. Preference would be from first to last.
Here's an example of a .salt-lint file: https://github.com/saltstack-formulas/openssh-formula/blob/master/.salt-lint