Feature request: Optional config file instead of CLI arguments about kube-score

[zegl]

Really cool to see the pre-commit hook btw!

[bjd2385]

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?

[bjd2385]

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.

[bjd2385]

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).