search

warpnet / salt-lint

A command-line utility that checks for best practices in SaltStack.
https://salt-lint.readthedocs.io/en/latest/
MIT License
154 stars 39 forks source link

Using `noqa` with multiline strings #317

Open tacerus opened 11 months ago

tacerus commented 11 months ago

Is your feature request related to a problem? Please describe.

Taking the following pillar as an example:

ssh_known_hosts:
    - >-
        github.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9

Here, it seems currently not possible to use noqa overrides. Since multiline strings are interpreted as literals, adding a # noqa: 204 at the end would make the YAML parser add # noqa: 204 to the end of the value.

Describe the solution you'd like

I think a desirable route would be having noqa supported next to the list marker:

ssh_known_hosts:
    - >-  # noqa 204       <-- here
        github.com ssh-rsa 
...

I am not sure if there is anything in the YAML specification which makes this a bad practice, but it seems to parse fine, and avoids the need for an additional line.

Describe alternatives you've considered

An alternative would be supporting noqa in Jinja comments without spaces, that way it could be kept at the end of the line. However {#- noqa 204 #} makes the line even longer than needed.

Jinja comments with whitespace ({# noqa 204 #}, for example) are already supported, but introduce undesired formatting in the rendered file.

Additional context n/a

tacerus commented 11 months ago

I proposed a patch here:

https://github.com/warpnet/salt-lint/pull/318

It is not completely perfect, it would be nice if the noqa would apply to all lines inside the multiline string, not just the first line. Feedback welcome.