Adopt KRM for `apko` file format

[maintainer mattmoor]: (this got a little rambly, but hopefully it makes sense) I don't see them as mutually exclusive TBH. Given that JSON is valid yaml, there's nothing stopping the use of kyaml transformers prior to apko_config's config_contents or even between apko_config and apko_build. I would say the most interesting manipulation of the config (apko_config) is the production of a "locked" file form which is a task that has a level of semantic depth beyond what something like kustomize or kpt could do, since it requires a fairly deep semantic understanding. apko show-packages can be used to get a similar package list directly from apko FWIW. That said, in my mind the main feature of terraform isn't the templating, it is enabling an orchestrated composition of tools, e.g. describing how we take an apko SBOM and attest it with cosign, or tag the resulting digest based on package versions, ...

Context: Issue chainguard-dev/apko#725 (closed, 10 comments): Once you have your image configs and build scripts setup, the majority of the work involved in operating a secure software factory is config management. Kubernetes ecosystem has great config management tooling and libraries, which comes as no surprise given that the Kubernetes Resource Model (KRM) was designed with that intent. Virtually all manipulation that needs to ta

Source: Issue chainguard-dev/apko#725 (closed, 10 comments): Once you have your image configs and build scripts setup, the majority of the work involved in operating a secure software factory is config management. Kubernetes ecosystem has great config management tooling and libraries, which comes as no surprise given that the Kubernetes Resource Model (KRM) was designed with that intent. Virtually all manipulation that needs to ta

Verified resolution: [maintainer mattmoor]: (this got a little rambly, but hopefully it makes sense) I don't see them as mutually exclusive TBH. Given that JSON is valid yaml, there's nothing stopping the use of kyaml transformers prior to apko_config's config_contents or even between apko_config and apko_build. I would say the most interesting manipulation of the config (apko_config) is the production of a "locked" file form which is a task that has a level of semantic depth beyond what something like kustomize or kpt could do, since it requires a fairly deep semantic understanding. apko show-packages can be used to get a similar package list directly from apko FWIW. That said, in my mind the main feature of terraform isn't the templating, it is enabling an orchestrated composition of tools, e.g. describing how we take an apko SBOM and attest it with cosign, or tag the resulting digest based on package versions, ...

Source URL: https://github.com/chainguard-dev/apko/issues/725