Makes the colors look nicer with solarized dark. We probably need to
make solarized an option and have them default to look nice with basic
ansi colors.
Make the log messages clear and readable, for example:
holos render --log-format=json --log-level=debug \
--cluster-name core2 ./docs/examples/platforms/reference/projects/secrets/components/namespaces/ \
2> >(jq -r '"\(.source.file):\(.source.line)\t" + .msg')
The msg field is intended to have an imperative verb, ideally in the
past tense, followed by an actionable noun. Past tense indicates
success where as the "could not foo: "+err error form indicates an
attempt to do something that failed.
config.go:91 finalized config from flags
builder.go:115 cue export --out yaml ./platforms/reference/projects/secrets/components/namespaces
builder.go:85 wrote deploy/clusters/core2/components/prod-secrets-namespaces/prod-secrets-namespaces.gen.yaml
render.go:30 rendered prod-secrets-namespaces
Write the result of the cue evaluation to a cluster specific path for
git ops. The written file works with kubectl apply -f and a future
change will add the flux Kustomization and ArgoCD Application resources
to manage the same api objects using a gitops method.
holos render --cluster-name core2 ./docs/examples/platforms/reference/projects/secrets/components/namespaces/
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.
Without this patch holos --version printed to os.Stderr and used the
default cobra template. This is incompatible with our use of `git tag
v$(./bin/holos --version)`.
This patch minimally wires up a basic cue based component to produce
rendered api objects on standard output.
```bash
(cd docs/examples && holos build ./platforms/reference/projects/secrets/components/namespaces)
```
```yaml
metadata:
name: external-secrets
labels:
kubernetes.io/metadata.name: external-secrets
kind: Namespace
apiVersion: v1
```
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
