Feature Request: Support .salt-lint config files

[mattboston]

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.

• Project root folder
• User home directory
• OS dependent config folder (i.e. Linux ~/.config/...., Windows c:\Users\username\AppData...., MacOS ~/Library/Application Support/....)

Here's an example of a .salt-lint file: https://github.com/saltstack-formulas/openssh-formula/blob/master/.salt-lint

[jamesharr]

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

[jamesharr]

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?

[jamesharr]

@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?

[jbouter]

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.

[jamesharr]

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)

[mattboston]

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

[jamesharr]

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

• the PWD will be salt/roles/webserver
• the only .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.