Jeroen Op 't Eynde

I went down the rabbit hole and brought back a jsonnet library: https://github.com/Duologic/validate-libsonnet

Only `tk eval` takes top-level arguments, that is by design. The environments should be a bit more hermetic. This blogpost might inspire you for your use case: https://grafana.com/blog/2021/07/12/best-practices-for-consistent-configuration-management-at-scale-with-tanka/ The idea...

Regardless of implementing this feature or not, it is a good (gitops) practice to commit 'environment specific data' somewhere at least. Perhaps you can further explain your use case so...

Perhaps you can call it twice, once with CRDs and controller enabled and explicitly gateway disabled. Second the other way around.

I was able to get it execute this way: ``` local tanka = import 'github.com/grafana/jsonnet-libs/tanka-util/main.libsonnet'; local helm = tanka.helm.new(std.thisFile); { _config:: { ns: 'kong', }, kong_ingress_controller: helm.template('kong', './charts/ingress/', { namespace:...

The duplication protection prevents unintended ambiguity. Imagine you have a Deployment defined twice, but one of them has `replicas: 1` and the other `replicas: 10`, which value should Tanka choose?...

That's a good question. This initial PR simply syncs the schema with the types on the same branch, I'd suggest we match the schema sync that way along with the...

Would y'all be less opposed to only having to generate and maintain the JSON schema? Then we can move the library itself into Grafonnet while keeping up with the releases...

The actual generator is not in here, that's the CRDsonnet package, the generator directory here holds the specific code for generating this library.

I've put this into a separate repo: https://github.com/grafana/grafana-zabbix-libsonnet/