Skip to content
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

panlint: implement #nolint pragma #141

Open
wdpypere opened this issue Mar 1, 2017 · 8 comments
Open

panlint: implement #nolint pragma #141

wdpypere opened this issue Mar 1, 2017 · 8 comments
Assignees
Labels

Comments

@wdpypere
Copy link
Contributor

wdpypere commented Mar 1, 2017

As I started using panlint to cleanup our tree I found it fails for ssh authorized keys on line too long.
Now I could not find a way to exclude them, or split them in a functional way to keep panlint happy as well as maintain the expected output in the profile.

@jrha
Copy link
Member

jrha commented Mar 2, 2017

We encounter the same problem and simply ignore the errors for those files, do you have a better idea for how to handle this?

@wdpypere
Copy link
Contributor Author

wdpypere commented Mar 9, 2017

well, we run panlint as a test on changes so having a --exclude option or something and then a regex for something like "ssh-rsa " ?

@wdpypere
Copy link
Contributor Author

wdpypere commented Apr 4, 2017

We now load the ssh keys in a different way, so this is no longer an issue for us. afaik, this can be closed.

@ned21
Copy link
Contributor

ned21 commented Nov 8, 2019

We've had this problem with a couple of other lines where we are embedding content. How about a generic #nolint pragma to tell panlint to ignore the following lines?

@ned21 ned21 changed the title panlint: ssh keys - line too long panlint: implement #nolint pragma Nov 8, 2019
@gombasg
Copy link
Contributor

gombasg commented Nov 8, 2019

Yup, I've seen panlint complaining path literals should not have trailing slashes - except those strings were not Pan path literals.

No static analyzers can ever be perfect, so having a way for suppressing certain warnings is necessary.

@jrha
Copy link
Member

jrha commented Nov 11, 2019

Could you take a look at #220? The rest of the changes that follow the re-factoring work there provide such functionality.

@ned21
Copy link
Contributor

ned21 commented Nov 11, 2019

@jrha I am happy with #220 but it depends on #219 where I hadn't reviewed the regexes in detail to be confident of merging it. And now we have #222 which will probably invalidate both of them. In which order do we proceed?

@wpoely86
Copy link
Member

It's not that much work to redo #222 on top of the other two if that helps.

@jrha jrha added the panlint label Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants