Content seems more appropriate of a field name, and it makes sense since
we are likely to output other formats than yaml, probably json too. We
need to discriminate on content type, so also add a contentType field.
Semantics are meant to be the same has the http content type header, but
simple.
The intent is for all of the output formats to share a common `name`
field, useful to construct a file name to write rendered output to for
git ops.
This is equivalent to the OrderedComponent name specified in the
platform.yaml in the prototype.
Leaf directories can output different kinds of things:
1. Platform specification. A list of components to manage.
2. Kubernetes API Objects suitable for kubectl apply -f- and friends.
3. Helm values to provide to a helm chart to render API objects.
This patch adds an output schema and a kind discriminator so the holos
cli can figure out what type of output it's working with. This makes it
possible to have a single `holos build <directory>` command that does
the right thing.
This patch adds the first platform component built with CUE. The intent
is to give a concrete use case for migrating the platform.yaml spec over
to the new approach with CUE.
This component is a simple namespace for the external secrets operator.
The majority of this patch is in setting up the structure of the CUE
module. The component is _not_ wired up to the holos cli yet, instead
it's built directly with cue using:
cd ./docs/examples/
cue export --out text -t cluster=core1 -e out ./platforms/reference/projects/secrets/components/namespaces/...
The command produces the same output as the was previously produced
using helm templates [here][1].
[1]: https://github.com/holos-run/holos-infra/blob/v0.4.0/deploy/clusters/core1/components/prod-secrets-namespaces/prod-secrets-namespaces.nofmt.yaml
