docs-v1/design_proposals/support-jsonnet-configuration.md
skaffold fix. Team acknowledges this is a good feature to have. @S-Bohn and skaffold team could probably pick this up after skaffold modules work is in.When using Skaffold the creation of the configuration file sometimes requires a lot of repetition. This can be mitigated partly by using YAML anchors but may still require writing almost identical pieces of code multiple times.
Jsonnet is a data templating language which extends json by additional constructs like inheritance and functions to make it more expressive and reduce complexity. See the official site for further comparison with other languages.
Example 1: The use case is a project which consists of multiple very similar but still distinct small services. Each implement the same interface but implements a different external provider. This requires us to write an artifact block for each of them. Every block only differs in the name of the image and a few parameters passed to a common dockerfile. Additionally, for each service, a test entry needs to be created which again only differs in the image name. Adding a new service is a tedious and error-prone task. Using Jsonnet we could define those similar pieces as functions, create a list of services, and use array comprehension to create the artifact list. The result would be much cleaner, easier to read, shorter, and less likely subject to introduce mistakes.
Example 2: We have a project where we currently generate multiple variants of the Kubernetes deployment manifests. We sometimes require to change a small particular option based on operational needs. To avoid creating constantly code changes we generate those different variants beforehand and create multiple (manual) continuous deployment jobs to bring them into production when needed. It is easy and convenient to using Kustomize to create the overlays and Skaffold to render the manifest variations. We create a profile for each of them which creates some line noise because we have to add each variant with only very few differences. Once all variants are written one has to repeat them for the staging environment. With Jsonnet this shrinks to a simple array comprehension.
$ wc skaffold.jsonnet skaffold.yaml
69 137 1634 skaffold.jsonnet
289 423 6719 skaffold.yaml
skaffold.yaml file. Requires a manual step before using Skaffold.The proposal is to allow Jsonnet as an allowed language to write the configuration file. Jsonnet returns by default pure JSON. Given that YAML is a superset of JSON the integration can be handled seamlessly during the loading of the configuration file. The parser can be reused without requiring a change.
From a user perspective, the only change is that the configuration file can be written in a different language. No further change in the configuration required. No interface changes required.
Jsonnet allows specification of top-level and external arguments using the command line interface. Is this something Skaffold should support?
Resolution: Not Yet Resolved
How should Jsonnet library search paths be specified?
Resolution: Not Yet Resolved
I am unsure about the integration tests. Given that no real change besides a different language dialect is used. Just rewrite the quickstart example in Jsonnet?
Resolution: Not Yet Resolved
go-jsonnet as a new dependency and use it to render Jsonnet configuration files during the load step. Could be made explicit by requiring that the command line option for configuration file (-f) points to a file with .jsonnet file extension.parseJSON and parseYAML. This would allow further modularization by giving a simple way to use YAML for static settings a extend it for repetitive portions in Jsonnet.
local common = std.native('parseYaml')(importstr 'skaffold-common.yaml');
local artifacts = ...; // list of artifact objects
common + {
build: {artifacts: artifacts}
}
Please describe what new test cases you are going to consider.