-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: integrate salint rules #19
Comments
Thanks @max-arnold for your feature request! I'm going to take a stab at a PR in the upcoming days, I've been thinking about a feature like this since the beginning of salt-lint. |
I'm now able to locally render the state which would be able to catch errors in simple states. There are however a few disadvantages to rendering the states:
{% if salt['pillar.get']('test') %}
test:
file.touch:
- name: /tmp/test
- require:
- test: test2
- wathc_in: # <-- typo here, should be watch_in
- service: some-service
{% endif %} While I still would like to implement this feature, I don't think all To allow somewhat more complex rules, I'm also working om a YAML renderer in #37. Using this feature we can easily add rules to check for deprecated options and for things like {% if salt['pillar.get']('test') %}
test:
cmd: # standard declaration
- wait
- name: mycommand
...
test:
cmd.wait: # inline function declaration
- name: mycommand
...
{% endif %} |
Making this feature opt-in is a completely reasonable thing to do. This is also good from a security perspective (the state rendering process could have side effects).
Could you please elaborate on why it needs to work this way?
This is super cool! When I asked for a possibility to inject custom config values, one of the use-cases I had in mind is to be able to flip deprecation settings like the |
This issue saltstack/salt#5378 (and the ones referenced inside) could provide more hints of what other people want from a Salt linter. |
I also feel obligated to repost a discussion from Slack (that happened recently) while it is still available, just for a future reference:
--- subthread ---
|
Having ability to render state files will also (correct me if I'm wrong) allow us to discover all type of syntax errors - so I like this direction even if it will slow check a bit 👍 |
Thanks @dawidmalina for your comment! I've updated the priority accordingly. Hope to get some work done on the feature request in the next couple of weeks. |
@roaldnefs i have very simple rule to validate (render) sls file: https://github.com/dawidmalina/salt-lint/blob/sls/saltlint/rules/StateCanBeRendered.py If you are interested in I can drop a pull request with this. |
What do you think about integrating all rules from the (probably unmaintained) salint package into salt-lint?
It is able to catch things like this one:
Also, it would be nice to be able to inject custom config values here https://github.com/gtmanfred/salint/blob/master/salint/script.py#L17 and specify pillar/grain fixtures.
The text was updated successfully, but these errors were encountered: