Open emmeowzing opened 1 year ago
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.
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?
Really cool to see the pre-commit hook btw!
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.
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).
Which version of kube-score are you using?
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.