Feature request: Optional config file instead of CLI arguments

[emmeowzing]

Which version of kube-score are you using?

$ kube-score version
kube-score version: 1.14.0, commit: 3d6392471f65c47a1c617d78d9f84a53457c5f5d, built: 2022-02-17T10:07:32Z

What did you do?

Wrote a simple pre-commit hook.

https://github.com/bjd2385/kube-score-pre-commit-hook

What did you expect to see?

Would be cool to just keep a configuration .score-file or something similar in the repository so we don't have to parse CLI args in scripts for either Helm or Kustomize from kube-score CLI args. It'd help with writing tests.

What did you see instead?

Had to pass CLI flags with arguments.

[emmeowzing]

Additional motivation: I use tools like chart-testing and this tool uses a config file of its own, for instance. Would be neat if this tool could follow a similar usage pattern.

[zegl]

A configuration file has been discussed before (#231, #384, and most recently in #468), and it's still a bit unclear to me what problems we would solve by adding a third way of configuring kube-score (--flags, and in-object annotations).

Do you have an example of what you would like to configure with the help of a configuration file that's hard to configure with flags or annotations today?

[zegl]

Really cool to see the pre-commit hook btw!

[emmeowzing]

Hey @zegl, so --flags have to be parsed out alongside supplied helm charts in the pre-commit script. So in my hook's example readme,

hooks:
      - id: kube-score
        args:
          - chart1-dir
          - chart2-dir
          - ...

it's relatively easy to supply and parse out Helm chart directories as args, but I think to configure kube-score alongside those args, it would be pretty difficult; especially with a variable number of potential helm chart directories and config flags.

[emmeowzing]

Again, following the pattern of chart-testing from the Helm project, I've used config files like the following.

# helm chart locations to score, say
chart-dirs:
  - apps/helm-apps
  - helm
excluded-charts:
  - metrics-server
# chart-testing configuration options below
check-version-increment: true
lint-conf: .helm-lint.yaml
target-branch: master
remote: origin
validate-maintainers: false
exclude-deprecated: true

so maybe, we tell kube-score where our charts generally live, which charts in those locations to specifically exclude, along with a few kube-score-specific config flags after that. Of course, it doesn't have to be this complex.

Tbh, if it were just possible to stash either kube-score config or helm chart lists in the config, that would help, but following a similar pattern would be neat for engineers using either or both tools in any given project. It may help adoption some as well (e.g. I know I'd use this anywhere I was using chart-testing, and vice versa).