search

stackrox / kube-linter

KubeLinter is a static analysis tool that checks Kubernetes YAML files and Helm charts to ensure the applications represented in them adhere to best practices.
https://docs.kubelinter.io/
Apache License 2.0
2.98k stars 234 forks source link

[FEATURE_REQUEST] Use .kube-linter.yml in chart directory #533

Open PascalTurbo opened 1 year ago

PascalTurbo commented 1 year ago

Description of the problem/feature request Currently when using a .kube-linter.y(a)ml file, kube-linter searches for this configuration file at the place, where kube-linter is executed. This makes it impossible to use the well-known-configuration file pattern when using kube-linter container image.

Description of the existing behavior vs. expected behavior .kube-linter.y(a)ml file should be searched for in the path given as linting context. F.e. kube-linter lint ./my-fancy-helm-chart should search for .kube-linter.y(a)ml in my-fancy-helm-chart path and not in the current path.

janisz commented 1 year ago

To clarify, you are suggesting that kube-linter should search for the .kube-linter.yaml configuration file in the directory being checked, rather than the directory where kube-linter is executed. However, the current behavior of kube-linter is consistent with other linters like golangci-lint, which also search for the configuration file in the directory where the tool is executed.

To specify a configuration file in a different directory, you need to use the --config flag to provide the path to the configuration file. Keep in mind that changing the behavior of kube-linter could potentially be a breaking change for some users who rely on the current behavior. Therefore, any changes to the behavior of kube-linter should be carefully considered and documented to avoid confusion or unexpected behavior.

PascalTurbo commented 1 year ago

I think it would be nescessary to remove the current behavior. Just add an additional search path for the .kube-linter.yaml. This shouldn't break anything in most cases.

Alternatively an option for adding more search paths would also be a solution. This differs from the --config option by not failing if file doesn't exist.

The big deal in placing the configure file in the source code folder is, that you can follow convention-over-configuration pattern. If developers needs to configure something, they create a .kube-linter.yaml. If not, they can leave it out. We f.e. using kube-linter as a tekton task. With the current behavior it is impossible to use the .kube-linter.yaml. The only way is to explicitly configure the configuration path.