-
Notifications
You must be signed in to change notification settings - Fork 278
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
1.35.0 broke the "ignore" feature #657
Comments
Hello Matthias, thanks for the clear explanation, with a reproducer 👍 With this configuration: extends: default
ignore: test.yaml
May I ask how you encounter the problem? How you call yamllint? With the failing YAML file passed as an explicit argument? I'm not sure whether the old or the new behavior is better. On the one hand, it doesn't make sense to ignore a file that is explicitely passed as argument to the command. But on the other hand, doing is more consistent between how the global extends: default
ignore: test.yaml
rules:
key-duplicates:
ignore: test.yaml (in the above example, |
Same problem here. This .yamllint code block ignore: |
.clang-format
.clang-tidy
.yamllint
Is not ignoring the files correctly, as in my pre-commit run, the file is not ignored: Checking and linting yaml files internals................................Failed
.clang-format |
I'm having the same problem. I got a clang-format line, which exceeds 140 characters. It should be ignored by the yamllint. But it is not ignored in my Jenkins, and it is braking the build.
The version working version is: 1.31 |
Luis, Carlos, same question: how do you encounter the problem? How do you call yamllint? With the failing YAML file passed as an explicit argument? |
Hi Adrien, we currently use the following call for yamllint that is explict: find . -type f \( -name '*\.yaml' -or -name '*\.yml' \) -and -not \( -path './*templates/*' -or -name '*helmfile.yaml' \) -print0 | xargs -0 yamllint /cc @baurmatt |
@adrienverge We got a pipline on a Jenkins which uses pre-commit. On the pre-commit config we got this section:
Each time that the Jenkins is execute it clears the pre-commit and updates the hooks.
|
Commit 2344380 "Cleanly skip broken symlinks that are ignored" fixed a problem on symbolic links but also introduced a change on how ignored files should be treated, depending on whether they're explicitely passed as command-line arguments or not [^1]. This change is annoying for users that dynamically build the list of files to pass as arguments, e.g. [^2]: find -name '*\.yaml' | xargs yamllint The present commit adds unit tests for `yamllint [FILES]...` and `yamllint --list-files [FILES]...`, that passed with previous version 1.34.0, and restore the behavior of this version. As a result it also reverts the API change of commit 2344380 on `yamllint.linter.run(stream, config)`. [^1]: #657 (comment) [^2]: #657 (comment)
Commit 2344380 "Cleanly skip broken symlinks that are ignored" fixed a problem on symbolic links but also introduced a change on how ignored files should be treated, depending on whether they're explicitely passed as command-line arguments or not [^1]. This change is annoying for users that dynamically build the list of files to pass as arguments, e.g. [^2]: find -name '*\.yaml' | xargs yamllint The present commit adds unit tests for `yamllint [FILES]...` and `yamllint --list-files [FILES]...`, that passed with previous version 1.34.0, and restore the behavior of this version. As a result it also reverts the API change of commit 2344380 on `yamllint.linter.run(stream, config)`. [^1]: #657 (comment) [^2]: #657 (comment)
@hardoverflow thanks, this is indeed a use-case that seems legitimate. I created #658 to restore the previous behavior, and released it in yamllint version 1.35.1. |
Thanks for the quick response and the bug fix. Thanks also for such a great tool! From my point of view, the issue can be closed. The bugfix works as expected. |
Hey,
first of all: thanks for this project! Basically all of our CI pipelines use it! :)
Sadly we found that the latest (1.35.0) release broken the "Ignoring paths" feature which we use to get some of your pipeline green :) I've created a reproduction case in the hope that this helps to narrow down the problem:
Thanks!
Regards,
Matthias
The text was updated successfully, but these errors were encountered: