docs: add generate platform to hello holos (#311)

docs: rewrite technical overview for v1alpha5

.cspell.json

@@ -34,12 +34,14 @@
     "blackbox",
     "buildplan",
     "builtinpluginloadingoptions",
+    "cachedir",
     "cadvisor",
     "cainjector",
     "CAROOT",
     "certificaterequest",
     "certificaterequests",
     "certificatesigningrequests",
+    "clientset",
     "clsx",
     "clusterexternalsecret",
     "clusterexternalsecrets",
@@ -50,8 +52,10 @@
     "clustersecretstore",
     "clustersecretstores",
     "clusterwide",
+    "Cmds",
     "CNCF",
     "CODEOWNERS",
+    "configdir",
     "configmap",
     "configmapargs",
     "connectrpc",
@@ -101,6 +105,7 @@
     "ghaction",
     "githubaccesstokens",
     "gitops",
+    "GOBIN",
     "godoc",
     "golangci",
     "gomarkdoc",
@@ -170,6 +175,7 @@
     "Multicluster",
     "mutatingwebhookconfiguration",
     "mutatingwebhookconfigurations",
+    "mvdan",
     "mxcl",
     "myhostname",
     "myRegistrKeySecretName",
@@ -184,9 +190,11 @@
     "oauthproxy",
     "objectmap",
     "objectmeta",
+    "omitempty",
     "organizationconnect",
     "orgid",
     "otelconnect",
+    "outfile",
     "overriden",
     "Parentspanid",
     "patchstrategicmerge",
@@ -238,6 +246,7 @@
     "requestauthentications",
     "resourcequotas",
     "retryable",
+    "rogpeppe",
     "rolebinding",
     "rootfs",
     "ropc",
@@ -274,6 +283,7 @@
     "systemconnect",
     "tablewriter",
     "templatable",
+    "testscript",
     "thanos",
     "Tiltfile",
     "timestamppb",
@@ -306,6 +316,7 @@
     "volumeattachments",
     "wasmplugin",
     "wasmplugins",
+    "workdir",
     "workloadentries",
     "workloadentry",
     "workloadgroup",

.github/workflows/test.yaml

@@ -13,7 +13,7 @@ permissions:
 
 jobs:
   test:
-    runs-on: gha-rs
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout code
         uses: actions/checkout@v4
@@ -35,7 +35,7 @@ jobs:
         uses: azure/setup-helm@v4
 
       - name: Set up Kubectl
-        uses: azure/setup-kubectl@v3
+        uses: azure/setup-kubectl@v4
 
       - name: Install Tools
         run: |

Makefile

@@ -150,6 +150,10 @@ dev-deploy: install image  ## deploy to dev
 website: ## Build website
 	./hack/build-website
 
+.PHONY: unity
+unity: ## https://cuelabs.dev/unity/
+	./scripts/unity
+
 .PHONY: help
 help:  ## Display this help menu.
 	@awk 'BEGIN {FS = ":.*##"; printf "\nUsage:\n  make \033[36m<target>\033[0m\n"} /^[a-zA-Z_0-9-]+:.*?##/ { printf "  \033[36m%-20s\033[0m %s\n", $$1, $$2 } /^##@/ { printf "\n\033[1m%s\033[0m\n", substr($$0, 5) } ' $(MAKEFILE_LIST)

api/author/v1alpha5/definitions.go

@@ -0,0 +1,141 @@
+// Package author contains a standard set of schemas for component authors to
+// generate common [core] BuildPlans.
+//
+// Holos values stability, flexibility, and composition.  This package
+// intentionally defines only the minimal necessary set of structures.
+// Component authors are encouraged to define their own structures building on
+// our example [topics].
+//
+// The Holos Maintainers may add definitions to this package if the community
+// identifies nearly all users must define the exact same structure.  Otherwise,
+// definitions should be added as a customizable example in [topics].
+//
+// For example, structures representing a cluster and environment almost always
+// need to be defined.  Their definition varies from one organization to the
+// next.  Therefore, customizable definitions for a cluster and environment are
+// best maintained in [topics], not standardized in this package.
+//
+// [core]: https://holos.run/docs/api/core/
+// [topics]: https://holos.run/docs/topics/
+package author
+
+import core "github.com/holos-run/holos/api/core/v1alpha5"
+
+//go:generate ../../../hack/gendoc
+
+// Platform assembles a core Platform in the Resource field for the holos render
+// platform command.  Use the Components field to register components with the
+// platform.
+type Platform struct {
+	Name       string
+	Components map[NameLabel]core.Component
+	Resource   core.Platform
+}
+
+// ComponentConfig represents the configuration common to all kinds of
+// components for use with the holos render component command.  All component
+// kinds may be transformed with [kustomize] configured with the
+// [KustomizeConfig] field.
+//
+//   - [Helm] charts.
+//   - [Kubernetes] resources generated from CUE.
+//   - [Kustomize] bases.
+//
+// [kustomize]: https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/
+type ComponentConfig struct {
+	// Name represents the BuildPlan metadata.name field.  Used to construct the
+	// fully rendered manifest file path.
+	Name string
+	// Path represents the path to the component producing the BuildPlan.
+	Path string
+	// Parameters are useful to reuse a component with various parameters.
+	// Injected as CUE @tag variables.  Parameters with a "holos_" prefix are
+	// reserved for use by the Holos Authors.
+	Parameters map[string]string
+	// OutputBaseDir represents the output base directory used when assembling
+	// artifacts.  Useful to organize components by clusters or other parameters.
+	// For example, holos writes resource manifests to
+	// {WriteTo}/{OutputBaseDir}/components/{Name}/{Name}.gen.yaml
+	OutputBaseDir string `cue:"string | *\"\""`
+
+	// Resources represents kubernetes resources mixed into the rendered manifest.
+	Resources core.Resources
+	// KustomizeConfig represents the configuration kustomize.
+	KustomizeConfig KustomizeConfig
+	// Artifacts represents additional artifacts to mix in.  Useful for adding
+	// GitOps resources.  Each Artifact is unified without modification into the
+	// BuildPlan.
+	Artifacts map[NameLabel]core.Artifact
+}
+
+// Helm assembles a BuildPlan rendering a helm chart.  Useful to mix in
+// additional resources from CUE and transform the helm output with kustomize.
+type Helm struct {
+	ComponentConfig `json:",inline"`
+
+	// Chart represents a Helm chart.
+	Chart core.Chart
+	// Values represents data to marshal into a values.yaml for helm.
+	Values core.Values
+	// EnableHooks enables helm hooks when executing the `helm template` command.
+	EnableHooks bool `cue:"true | *false"`
+	// Namespace sets the helm chart namespace flag if provided.
+	Namespace string `json:",omitempty"`
+
+	// BuildPlan represents the derived BuildPlan produced for the holos render
+	// component command.
+	BuildPlan core.BuildPlan
+}
+
+// Kubernetes assembles a BuildPlan containing inline resources exported from
+// CUE.
+type Kubernetes struct {
+	ComponentConfig `json:",inline"`
+
+	// BuildPlan represents the derived BuildPlan produced for the holos render
+	// component command.
+	BuildPlan core.BuildPlan
+}
+
+// Kustomize assembles a BuildPlan rendering manifests from a [kustomize]
+// kustomization.
+//
+// [kustomize]: https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/
+type Kustomize struct {
+	ComponentConfig `json:",inline"`
+
+	// BuildPlan represents the derived BuildPlan produced for the holos render
+	// component command.
+	BuildPlan core.BuildPlan
+}
+
+// KustomizeConfig represents the configuration for [kustomize] post processing.
+// Use the Files field to mix in plain manifest files located in the component
+// directory.  Use the Resources field to mix in manifests from network urls.
+//
+// [kustomize]: https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/
+type KustomizeConfig struct {
+	// Kustomization represents the kustomization used to transform resources.
+	// Note the resources field is internally managed from the Files and Resources fields.
+	Kustomization map[string]any `json:",omitempty"`
+	// Files represents files to copy from the component directory for kustomization.
+	Files map[string]struct{ Source string } `cue:"{[NAME=_]: Source: NAME}"`
+	// Resources represents additional entries to included in the resources list.
+	Resources map[string]struct{ Source string } `cue:"{[NAME=_]: Source: NAME}"`
+	// CommonLabels represents common labels added without including selectors.
+	CommonLabels map[string]string
+}
+
+// NameLabel represents the common use case of converting a struct to a list
+// where the name field of each value unifies with the field name of the outer
+// struct.
+//
+// For example:
+//
+//	S: [NameLabel=string]: name: NameLabel
+//	S: jeff: _
+//	S: gary: _
+//	S: nate: _
+//	L: [for x in S {x}]
+//	// L is [{name: "jeff"}, {name: "gary"}, {name: "nate"}]
+type NameLabel string

api/author/v1alpha5/header.yaml

@@ -0,0 +1,5 @@
+---
+title: Author Schemas
+description: Standardized schemas for component authors.
+sidebar_position: 200
+---

api/core/v1alpha4/header.yaml

@@ -1,4 +1,4 @@
 ---
-description: Core v1alpha2 schema for advanced use cases.
-sidebar_position: 996
+description: Core schema for holos to render a component BuildPlan.
+sidebar_position: 100
 ---

api/core/v1alpha5/header.yaml

@@ -0,0 +1,5 @@
+---
+title: Core Schemas
+description: BuildPlan defines the holos rendering pipeline.
+sidebar_position: 100
+---

api/core/v1alpha5/types.go

@@ -0,0 +1,275 @@
+// Package core contains schemas for a [Platform] and [BuildPlan].  Holos takes
+// a [Platform] as input, then iterates over each [Component] to produce a
+// [BuildPlan].  Holos processes the [BuildPlan] to produce fully rendered
+// manifests, each an [Artifact].
+package core
+
+//go:generate ../../../hack/gendoc
+
+// BuildPlan represents an implementation of the [rendered manifest pattern].
+// Holos processes a BuildPlan to produce one or more [Artifact] output files.
+// BuildPlan artifact files usually contain Kubernetes manifests, but they may
+// have any content.
+//
+// A BuildPlan usually produces two artifacts.  One artifact contains a manifest
+// of resources.  A second artifact contains a GitOps resource to manage the
+// first, usually an ArgoCD Application resource.
+//
+// Holos uses CUE to construct a BuildPlan.  A future enhancement will support
+// user defined executables providing a BuildPlan to Holos in the style of an
+// [external credential provider].
+//
+// [rendered manifest pattern]: https://akuity.io/blog/the-rendered-manifests-pattern
+// [external credential provider]: https://github.com/kubernetes/enhancements/blob/313ad8b59c80819659e1fbf0f165230f633f2b22/keps/sig-auth/541-external-credential-providers/README.md
+type BuildPlan struct {
+	// Kind represents the type of the resource.
+	Kind string `json:"kind" cue:"\"BuildPlan\""`
+	// APIVersion represents the versioned schema of the resource.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha5\""`
+	// Metadata represents data about the resource such as the Name.
+	Metadata Metadata `json:"metadata"`
+	// Spec specifies the desired state of the resource.
+	Spec BuildPlanSpec `json:"spec"`
+	// Source reflects the origin of the BuildPlan.
+	Source BuildPlanSource `json:"source,omitempty"`
+}
+
+// BuildPlanSpec represents the specification of the [BuildPlan].
+type BuildPlanSpec struct {
+	// Artifacts represents the artifacts for holos to build.
+	Artifacts []Artifact `json:"artifacts"`
+	// Disabled causes the holos cli to disregard the build plan.
+	Disabled bool `json:"disabled,omitempty"`
+}
+
+// BuildPlanSource reflects the origin of a [BuildPlan].  Useful to save a build
+// plan to a file, then re-generate it without needing to process a [Platform]
+// component collection.
+type BuildPlanSource struct {
+	// Component reflects the component that produced the build plan.
+	Component Component `json:"component,omitempty"`
+}
+
+// Artifact represents one fully rendered manifest produced by a [Transformer]
+// sequence, which transforms a [Generator] collection.  A [BuildPlan] produces
+// an [Artifact] collection.
+//
+// Each Artifact produces one manifest file artifact.  Generator Output values
+// are used as Transformer Inputs.  The Output field of the final [Transformer]
+// should have the same value as the Artifact field.
+//
+// When there is more than one [Generator] there must be at least one
+// [Transformer] to combine outputs into one Artifact.  If there is a single
+// Generator, it may directly produce the Artifact output.
+//
+// An Artifact is processed concurrently with other artifacts in the same
+// [BuildPlan].  An Artifact should not use an output from another Artifact as
+// an input.  Each [Generator] may also run concurrently.  Each [Transformer] is
+// executed sequentially starting after all generators have completed.
+//
+// Output fields are write-once.  It is an error for multiple Generators or
+// Transformers to produce the same Output value within the context of a
+// [BuildPlan].
+type Artifact struct {
+	Artifact     FilePath      `json:"artifact,omitempty"`
+	Generators   []Generator   `json:"generators,omitempty"`
+	Transformers []Transformer `json:"transformers,omitempty"`
+	Skip         bool          `json:"skip,omitempty"`
+}
+
+// Generator generates Kubernetes resources.  [Helm] and [Resources] are the
+// most commonly used, often paired together to mix-in resources to an
+// unmodified Helm chart.  A simple [File] generator is also available for use
+// with the [Kustomize] transformer.
+//
+// Each Generator in an [Artifact] must have a distinct Output value for a
+// [Transformer] to reference.
+//
+//  1. [Resources] - Generates resources from CUE code.
+//  2. [Helm] - Generates rendered yaml from a [Chart].
+//  3. [File] - Generates data by reading a file from the component directory.
+type Generator struct {
+	// Kind represents the kind of generator.  Must be Resources, Helm, or File.
+	Kind string `json:"kind" cue:"\"Resources\" | \"Helm\" | \"File\""`
+	// Output represents a file for a Transformer or Artifact to consume.
+	Output FilePath `json:"output"`
+	// Resources generator. Ignored unless kind is Resources.  Resources are
+	// stored as a two level struct.  The top level key is the Kind of resource,
+	// e.g. Namespace or Deployment.  The second level key is an arbitrary
+	// InternalLabel.  The third level is a map[string]any representing the
+	// Resource.
+	Resources Resources `json:"resources,omitempty"`
+	// Helm generator. Ignored unless kind is Helm.
+	Helm Helm `json:"helm,omitempty"`
+	// File generator. Ignored unless kind is File.
+	File File `json:"file,omitempty"`
+}
+
+// Resource represents one kubernetes api object.
+type Resource map[string]any
+
+// Resources represents Kubernetes resources.  Most commonly used to mix
+// resources into the [BuildPlan] generated from CUE, but may be generated from
+// elsewhere.
+type Resources map[Kind]map[InternalLabel]Resource
+
+// File represents a simple single file copy [Generator].  Useful with a
+// [Kustomize] [Transformer] to process plain manifest files stored in the
+// component directory.  Multiple File generators may be used to transform
+// multiple resources.
+type File struct {
+	// Source represents a file sub-path relative to the component path.
+	Source FilePath `json:"source"`
+}
+
+// Helm represents a [Chart] manifest [Generator].
+type Helm struct {
+	// Chart represents a helm chart to manage.
+	Chart Chart `json:"chart"`
+	// Values represents values for holos to marshal into values.yaml when
+	// rendering the chart.
+	Values Values `json:"values"`
+	// EnableHooks enables helm hooks when executing the `helm template` command.
+	EnableHooks bool `json:"enableHooks,omitempty"`
+	// Namespace represents the helm namespace flag
+	Namespace string `json:"namespace,omitempty"`
+}
+
+// Values represents [Helm] Chart values generated from CUE.
+type Values map[string]any
+
+// Chart represents a [Helm] Chart.
+type Chart struct {
+	// Name represents the chart name.
+	Name string `json:"name"`
+	// Version represents the chart version.
+	Version string `json:"version"`
+	// Release represents the chart release when executing helm template.
+	Release string `json:"release"`
+	// Repository represents the repository to fetch the chart from.
+	Repository Repository `json:"repository,omitempty"`
+}
+
+// Repository represents a [Helm] [Chart] repository.
+type Repository struct {
+	Name string `json:"name"`
+	URL  string `json:"url"`
+}
+
+// Transformer combines multiple inputs from prior [Generator] or [Transformer]
+// outputs into one output.  [Kustomize] is the most commonly used transformer.
+// A simple [Join] is also supported for use with plain manifest files.
+//
+//  1. [Kustomize] - Patch and transform the output from prior generators or
+//     transformers.  See [Introduction to Kustomize].
+//  2. [Join] - Concatenate multiple prior outputs into one output.
+//
+// [Introduction to Kustomize]: https://kubectl.docs.kubernetes.io/guides/config_management/introduction/
+type Transformer struct {
+	// Kind represents the kind of transformer. Must be Kustomize, or Join.
+	Kind string `json:"kind" cue:"\"Kustomize\" | \"Join\""`
+	// Inputs represents the files to transform. The Output of prior Generators
+	// and Transformers.
+	Inputs []FilePath `json:"inputs"`
+	// Output represents a file for a subsequent Transformer or Artifact to
+	// consume.
+	Output FilePath `json:"output"`
+	// Kustomize transformer. Ignored unless kind is Kustomize.
+	Kustomize Kustomize `json:"kustomize,omitempty"`
+	// Join transformer. Ignored unless kind is Join.
+	Join Join `json:"join,omitempty"`
+}
+
+// Join represents a [Transformer] using [bytes.Join] to concatenate multiple
+// inputs into one output with a separator.  Useful for combining output from
+// [Helm] and [Resources] together into one [Artifact] when [Kustomize] is
+// otherwise unnecessary.
+//
+// [bytes.Join]: https://pkg.go.dev/bytes#Join
+type Join struct {
+	Separator string `json:"separator" cue:"string | *\"---\\n\""`
+}
+
+// Kustomize represents a kustomization [Transformer].
+type Kustomize struct {
+	// Kustomization represents the decoded kustomization.yaml file
+	Kustomization Kustomization `json:"kustomization"`
+	// Files holds file contents for kustomize, e.g. patch files.
+	Files FileContentMap `json:"files,omitempty"`
+}
+
+// Kustomization represents a kustomization.yaml file for use with the
+// [Kustomize] [Transformer].  Untyped to avoid tightly coupling holos to
+// kubectl versions which was a problem for the Flux maintainers.  Type checking
+// is expected to happen in CUE against the kubectl version the user prefers.
+type Kustomization map[string]any
+
+// FileContent represents file contents.
+type FileContent string
+
+// FileContentMap represents a mapping of file paths to file contents.
+type FileContentMap map[FilePath]FileContent
+
+// FilePath represents a file path.
+type FilePath string
+
+// InternalLabel is an arbitrary unique identifier internal to holos itself.
+// The holos cli is expected to never write a InternalLabel value to rendered
+// output files, therefore use a InternalLabel when the identifier must be
+// unique and internal.  Defined as a type for clarity and type checking.
+type InternalLabel string
+
+// Kind is a discriminator. Defined as a type for clarity and type checking.
+type Kind string
+
+// Metadata represents data about the resource such as the Name.
+type Metadata struct {
+	// Name represents the resource name.
+	Name string `json:"name"`
+}
+
+// Platform represents a platform to manage.  A Platform specifies a [Component]
+// collection and integrates the components together into a holistic platform.
+// Holos iterates over the [Component] collection producing a [BuildPlan] for
+// each, which holos then executes to render manifests.
+//
+// Inspect a Platform resource holos would process by executing:
+//
+//	cue export --out yaml ./platform
+type Platform struct {
+	// Kind is a string value representing the resource.
+	Kind string `json:"kind" cue:"\"Platform\""`
+	// APIVersion represents the versioned schema of this resource.
+	APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha5\""`
+	// Metadata represents data about the resource such as the Name.
+	Metadata Metadata `json:"metadata"`
+
+	// Spec represents the platform specification.
+	Spec PlatformSpec `json:"spec"`
+}
+
+// PlatformSpec represents the platform specification.
+type PlatformSpec struct {
+	// Components represents a collection of holos components to manage.
+	Components []Component `json:"components"`
+}
+
+// Component represents the complete context necessary to produce a [BuildPlan]
+// from a path containing parameterized CUE configuration.
+type Component struct {
+	// Name represents the name of the component. Injected as the tag variable
+	// "holos_component_name".
+	Name string `json:"name"`
+	// Path represents the path of the component relative to the platform root.
+	// Injected as the tag variable "holos_component_path".
+	Path string `json:"path"`
+	// WriteTo represents the holos render component --write-to flag.  If empty,
+	// the default value for the --write-to flag is used.
+	WriteTo string `json:"writeTo,omitempty"`
+	// Parameters represent user defined input variables to produce various
+	// [BuildPlan] resources from one component path.  Injected as CUE @tag
+	// variables.  Parameters with a "holos_" prefix are reserved for use by the
+	// Holos Authors.  Multiple environments are a prime example of an input
+	// parameter that should always be user defined, never defined by Holos.
+	Parameters map[string]string `json:"parameters,omitempty"`
+}

cmd/holos/main_test.go

@@ -2,8 +2,10 @@ package main
 
 import (
 	"os"
+	"path/filepath"
 	"testing"
 
+	cue "cuelang.org/go/cmd/cue/cmd"
 	"github.com/holos-run/holos/internal/cli"
 	"github.com/rogpeppe/go-internal/testscript"
 )
@@ -11,11 +13,38 @@ import (
 func TestMain(m *testing.M) {
 	os.Exit(testscript.RunMain(m, map[string]func() int{
 		"holos": cli.MakeMain(),
+		"cue":   cue.Main,
 	}))
 }
 
-func TestGetSecrets(t *testing.T) {
-	testscript.Run(t, testscript.Params{
-		Dir: "testdata",
-	})
+func TestGuides_v1alpha4(t *testing.T) {
+	testscript.Run(t, params(filepath.Join("v1alpha4", "guides")))
+}
+func TestGuides_v1alpha5(t *testing.T) {
+	testscript.Run(t, params(filepath.Join("v1alpha5", "guides")))
+}
+
+func TestSchemas_v1alpha5(t *testing.T) {
+	testscript.Run(t, params(filepath.Join("v1alpha5", "schemas")))
+}
+
+func TestCLI(t *testing.T) {
+	testscript.Run(t, params("cli"))
+}
+
+func params(dir string) testscript.Params {
+	return testscript.Params{
+		Dir:                 filepath.Join("tests", dir),
+		RequireExplicitExec: true,
+		RequireUniqueNames:  os.Getenv("HOLOS_WORKDIR_ROOT") == "",
+		WorkdirRoot:         os.Getenv("HOLOS_WORKDIR_ROOT"),
+		UpdateScripts:       os.Getenv("HOLOS_UPDATE_SCRIPTS") != "",
+		Setup: func(env *testscript.Env) error {
+			// Just like cmd/cue/cmd.TestScript, set up separate cache and config dirs per test.
+			env.Setenv("CUE_CACHE_DIR", filepath.Join(env.WorkDir, "tmp/cachedir"))
+			configDir := filepath.Join(env.WorkDir, "tmp/configdir")
+			env.Setenv("CUE_CONFIG_DIR", configDir)
+			return nil
+		},
+	}
 }

cmd/holos/testdata/constraints.txt

@@ -1,34 +0,0 @@
-# Want support for intermediary constraints
-exec holos build ./foo/... --log-level debug
-stdout '^bf2bc7f9-9ba0-4f9e-9bd2-9a205627eb0b$'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- foo/constraints.cue --
-package holos
-
-metadata: name: "jeff"
--- foo/bar/bar.cue --
-package holos
-
-spec: components: KubernetesObjectsList: [
-  #KubernetesObjects & {
-    apiObjectMap: foo: bar: "bf2bc7f9-9ba0-4f9e-9bd2-9a205627eb0b"
-  }
-]
--- schema.cue --
-package holos
-
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-#KubernetesObjects: {
-	apiVersion: "holos.run/v1alpha1"
-	kind: "KubernetesObjects"
-	apiObjectMap: {...}
-}
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"

cmd/holos/testdata/issue15_cue_errors.txt

@@ -1,20 +0,0 @@
-# Want cue errors to show files and lines
-! exec holos build .
-stderr 'apiObjectMap.foo.bar: cannot convert incomplete value'
-stderr '/component.cue:\d+:\d+$'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- component.cue --
-package holos
-
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"
-spec: components: KubernetesObjectsList: [{apiObjectMap: foo: bar: _baz}]
-
-_baz: string

cmd/holos/testdata/issue25_apiobjects_cue.txt

@@ -1,61 +0,0 @@
-# Want kube api objects in the apiObjects output.
-exec holos build .
-stdout '^kind: SecretStore$'
-stdout '# Source: CUE apiObjects.SecretStore.default'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- component.cue --
-package holos
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"
-spec: components: KubernetesObjectsList: [{apiObjectMap: #APIObjects.apiObjectMap}]
-
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-#SecretStore: {
-    kind: string
-    metadata: name: string
-}
-
-#APIObjects: {
-  apiObjects: {
-    SecretStore: {
-      default: #SecretStore & { metadata: name: "default" }
-    }
-  }
-}
-
-
--- schema.cue --
-package holos
-
-// #APIObjects is the output type for api objects produced by cue.  A map is used to aid debugging and clarity.
-import "encoding/yaml"
-
-#APIObjects: {
-	// apiObjects holds each the api objects produced by cue.
-	apiObjects: {
-		[Kind=_]: {
-			[Name=_]: {
-				kind: Kind
-				metadata: name: Name
-			}
-		}
-	}
-
-	// apiObjectsContent holds the marshalled representation of apiObjects
-	apiObjectMap: {
-		for kind, v in apiObjects {
-			"\(kind)": {
-				for name, obj in v {
-				  "\(name)": yaml.Marshal(obj)
-			  }
-			}
-		}
-	}
-}

cmd/holos/testdata/issue25_apiobjects_helm.txt

@@ -1,62 +0,0 @@
-# Want kube api objects in the apiObjects output.
-exec holos build .
-stdout '^kind: SecretStore$'
-stdout '# Source: CUE apiObjects.SecretStore.default'
-stderr 'skipping helm: no chart name specified'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- component.cue --
-package holos
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"
-spec: components: HelmChartList: [{apiObjectMap: #APIObjects.apiObjectMap}]
-
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-#SecretStore: {
-    kind: string
-    metadata: name: string
-}
-
-#APIObjects: {
-  apiObjects: {
-    SecretStore: {
-      default: #SecretStore & { metadata: name: "default" }
-    }
-  }
-}
-
-
--- schema.cue --
-package holos
-
-// #APIObjects is the output type for api objects produced by cue.  A map is used to aid debugging and clarity.
-import "encoding/yaml"
-
-#APIObjects: {
-	// apiObjects holds each the api objects produced by cue.
-	apiObjects: {
-		[Kind=_]: {
-			[Name=_]: {
-				kind: Kind
-				metadata: name: Name
-			}
-		}
-	}
-
-	// apiObjectsContent holds the marshalled representation of apiObjects
-	apiObjectMap: {
-		for kind, v in apiObjects {
-			"\(kind)": {
-				for name, obj in v {
-				  "\(name)": yaml.Marshal(obj)
-			  }
-			}
-		}
-	}
-}

cmd/holos/testdata/issue25_show_object_names.txt

@@ -1,25 +0,0 @@
-# Want api object kind and name in errors
-! exec holos build .
-stderr 'apiObjects.secretstore.default.foo: field not allowed'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- component.cue --
-package holos
-
-apiVersion: "holos.run/v1alpha1"
-kind: "KubernetesObjects"
-cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-#SecretStore: {
-    metadata: name: string
-}
-
-apiObjects: {
-  secretstore: {
-    default: #SecretStore & { foo: "not allowed" }
-  }
-}

cmd/holos/testdata/issue33_helm_stderr.txt

@@ -1,289 +0,0 @@
-# Want helm errors to show up
-! exec holos build .
-stderr 'Error: execution error at \(zitadel/templates/secret_zitadel-masterkey.yaml:2:4\): Either set .Values.zitadel.masterkey xor .Values.zitadel.masterkeySecretName'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- zitadel.cue --
-package holos
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"
-spec: components: HelmChartList: [_HelmChart]
-
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-_HelmChart: {
-  apiVersion: "holos.run/v1alpha1"
-  kind: "HelmChart"
-  metadata: name: "zitadel"
-  namespace: "zitadel"
-  chart: {
-    name:    "zitadel"
-    version: "7.9.0"
-    release: name
-    repository: {
-      name: "zitadel"
-      url:  "https://charts.zitadel.com"
-    }
-  }
-}
-
--- vendor/zitadel/templates/secret_zitadel-masterkey.yaml --
-{{- if (or (and .Values.zitadel.masterkey .Values.zitadel.masterkeySecretName) (and (not .Values.zitadel.masterkey) (not .Values.zitadel.masterkeySecretName)) ) }}
-{{- fail "Either set .Values.zitadel.masterkey xor .Values.zitadel.masterkeySecretName" }}
-{{- end }}
-{{- if .Values.zitadel.masterkey -}}
-apiVersion: v1
-kind: Secret
-type: Opaque
-metadata:
-  name: zitadel-masterkey
-  {{- with .Values.zitadel.masterkeyAnnotations }}
-  annotations:
-    {{- toYaml . | nindent 4 }}
-  {{- end }}
-  labels:
-    {{- include "zitadel.labels" . | nindent 4 }}
-stringData:
-  masterkey: {{ .Values.zitadel.masterkey }}
-{{- end -}}
--- vendor/zitadel/Chart.yaml --
-apiVersion: v2
-appVersion: v2.46.0
-description: A Helm chart for ZITADEL
-icon: https://zitadel.com/zitadel-logo-dark.svg
-kubeVersion: '>= 1.21.0-0'
-maintainers:
-- email: support@zitadel.com
-  name: zitadel
-  url: https://zitadel.com
-name: zitadel
-type: application
-version: 7.9.0
--- vendor/zitadel/values.yaml --
-# Default values for zitadel.
-zitadel:
-  # The ZITADEL config under configmapConfig is written to a Kubernetes ConfigMap
-  # See all defaults here:
-  # https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml
-  configmapConfig:
-    ExternalSecure: true
-    Machine:
-      Identification:
-        Hostname:
-          Enabled: true
-        Webhook:
-          Enabled: false
-
-  # The ZITADEL config under secretConfig is written to a Kubernetes Secret
-  # See all defaults here:
-  # https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml
-  secretConfig:
-
-  # Annotations set on secretConfig secret
-  secretConfigAnnotations:
-    helm.sh/hook: pre-install,pre-upgrade
-    helm.sh/hook-delete-policy: before-hook-creation
-    helm.sh/hook-weight: "0"
-
-  # Reference the name of a secret that contains ZITADEL configuration.
-  configSecretName:
-  # The key under which the ZITADEL configuration is located in the secret.
-  configSecretKey: config-yaml
-
-  # ZITADEL uses the masterkey for symmetric encryption.
-  # You can generate it for example with tr -dc A-Za-z0-9 </dev/urandom | head -c 32
-  masterkey: ""
-  # Reference the name of the secret that contains the masterkey. The key should be named "masterkey".
-  # Note: Either zitadel.masterkey or zitadel.masterkeySecretName must be set
-  masterkeySecretName: ""
-
-  # Annotations set on masterkey secret
-  masterkeyAnnotations:
-    helm.sh/hook: pre-install,pre-upgrade
-    helm.sh/hook-delete-policy: before-hook-creation
-    helm.sh/hook-weight: "0"
-
-  # The CA Certificate needed for establishing secure database connections
-  dbSslCaCrt: ""
-
-  # The Secret containing the CA certificate at key ca.crt needed for establishing secure database connections
-  dbSslCaCrtSecret: ""
-
-  # The db admins secret containing the client certificate and key at tls.crt and tls.key needed for establishing secure database connections
-  dbSslAdminCrtSecret: ""
-
-  # The db users secret containing the client certificate and key at tls.crt and tls.key needed for establishing secure database connections
-  dbSslUserCrtSecret: ""
-
-  # Generate a self-signed certificate using an init container
-  # This will also mount the generated files to /etc/tls/ so that you can reference them in the pod.
-  # E.G. KeyPath: /etc/tls/tls.key CertPath: /etc/tls/tls.crt
-  # By default, the SAN DNS names include, localhost, the POD IP address and the POD name. You may include one more by using additionalDnsName like "my.zitadel.fqdn".
-  selfSignedCert:
-    enabled: false
-    additionalDnsName:
-
-replicaCount: 3
-
-image:
-  repository: ghcr.io/zitadel/zitadel
-  pullPolicy: IfNotPresent
-  # Overrides the image tag whose default is the chart appVersion.
-  tag: ""
-
-chownImage:
-  repository: alpine
-  pullPolicy: IfNotPresent
-  tag: "3.19"
-
-imagePullSecrets: []
-nameOverride: ""
-fullnameOverride: ""
-
-# Annotations to add to the deployment
-annotations: {}
-
-# Annotations to add to the configMap
-configMap:
-  annotations:
-    helm.sh/hook: pre-install,pre-upgrade
-    helm.sh/hook-delete-policy: before-hook-creation
-    helm.sh/hook-weight: "0"
-
-serviceAccount:
-  # Specifies whether a service account should be created
-  create: true
-  # Annotations to add to the service account
-  annotations:
-    helm.sh/hook: pre-install,pre-upgrade
-    helm.sh/hook-delete-policy: before-hook-creation
-    helm.sh/hook-weight: "0"
-  # The name of the service account to use.
-  # If not set and create is true, a name is generated using the fullname template
-  name: ""
-
-podAnnotations: {}
-
-podAdditionalLabels: {}
-
-podSecurityContext:
-  runAsNonRoot: true
-  runAsUser: 1000
-
-securityContext: {}
-
-# Additional environment variables
-env:
-  []
-  # - name: ZITADEL_DATABASE_POSTGRES_HOST
-  #   valueFrom:
-  #     secretKeyRef:
-  #       name: postgres-pguser-postgres
-  #       key: host
-
-service:
-  type: ClusterIP
-  # If service type is "ClusterIP", this can optionally be set to a fixed IP address.
-  clusterIP: ""
-  port: 8080
-  protocol: http2
-  annotations: {}
-  scheme: HTTP
-
-ingress:
-  enabled: false
-  className: ""
-  annotations: {}
-  hosts:
-    - host: localhost
-      paths:
-        - path: /
-          pathType: Prefix
-  tls: []
-
-resources: {}
-
-nodeSelector: {}
-
-tolerations: []
-
-affinity: {}
-
-topologySpreadConstraints: []
-
-initJob:
-  # Once ZITADEL is installed, the initJob can be disabled.
-  enabled: true
-  annotations:
-    helm.sh/hook: pre-install,pre-upgrade
-    helm.sh/hook-delete-policy: before-hook-creation
-    helm.sh/hook-weight: "1"
-  resources: {}
-  backoffLimit: 5
-  activeDeadlineSeconds: 300
-  extraContainers: []
-  podAnnotations: {}
-  # Available init commands :
-  # "": initialize ZITADEL instance (without skip anything)
-  # database: initialize only the database
-  # grant: set ALL grant to user
-  # user: initialize only the database user
-  # zitadel: initialize ZITADEL internals (skip "create user" and "create database")
-  command: ""
-
-setupJob:
-  annotations:
-    helm.sh/hook: pre-install,pre-upgrade
-    helm.sh/hook-delete-policy: before-hook-creation
-    helm.sh/hook-weight: "2"
-  resources: {}
-  activeDeadlineSeconds: 300
-  extraContainers: []
-  podAnnotations: {}
-  additionalArgs:
-    - "--init-projections=true"
-  machinekeyWriter:
-    image:
-      repository: bitnami/kubectl
-      tag: ""
-    resources: {}
-
-readinessProbe:
-  enabled: true
-  initialDelaySeconds: 0
-  periodSeconds: 5
-  failureThreshold: 3
-
-livenessProbe:
-  enabled: true
-  initialDelaySeconds: 0
-  periodSeconds: 5
-  failureThreshold: 3
-
-startupProbe:
-  enabled: true
-  periodSeconds: 1
-  failureThreshold: 30
-
-metrics:
-  enabled: false
-  serviceMonitor:
-    # If true, the chart creates a ServiceMonitor that is compatible with Prometheus Operator
-    # https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.ServiceMonitor.
-    # The Prometheus community Helm chart installs this operator
-    # https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#kube-prometheus-stack
-    enabled: false
-    honorLabels: false
-    honorTimestamps: true
-
-pdb:
-  enabled: false
-  # these values are used for the PDB and are mutally exclusive
-  minAvailable: 1
-  # maxUnavailable: 1
-  annotations: {}

cmd/holos/testdata/issue42_kustomize_build_kind.txt

@@ -1,39 +0,0 @@
-# Kustomize is a supported holos component kind
-exec holos render component --cluster-name=mycluster . --log-level=debug
-
-# Want generated output
-cmp want.yaml deploy/clusters/mycluster/components/kstest/kstest.gen.yaml
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- component.cue --
-package holos
-
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"
-spec: components: KustomizeBuildList: [{metadata: name: "kstest"}]
-
--- kustomization.yaml --
-apiVersion: kustomize.config.k8s.io/v1beta1
-kind: Kustomization
-namespace: mynamespace
-resources:
-- serviceaccount.yaml
-
--- serviceaccount.yaml --
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: test
-
--- want.yaml --
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: test
-  namespace: mynamespace

cmd/holos/testdata/issue72_disallow_unknown_fields.txt

@@ -1,17 +0,0 @@
-# https://github.com/holos-run/holos/issues/72
-# Want holos to fail on unknown fields to catch typos and aid refactors
-! exec holos build .
-stderr 'unknown field \\"TypoKubernetesObjectsList\\"'
-
--- platform.config.json --
-{}
--- cue.mod --
-package holos
--- component.cue --
-package holos
-_cluster: string @tag(cluster, string)
-_platform_config: string @tag(platform_config, string)
-
-apiVersion: "holos.run/v1alpha1"
-kind: "BuildPlan"
-spec: components: TypoKubernetesObjectsList: []

cmd/holos/tests/v1alpha5/schemas/kubernetes.txt

@@ -0,0 +1,52 @@
+# author.#Kubernetes
+
+# Start in an empty directory.
+cd $WORK
+
+# Generate the directory structure we're going to work in.
+exec holos generate platform v1alpha5 --force
+
+# Platforms are empty by default.
+exec holos render platform ./platform
+stderr -count=1 '^rendered platform'
+
+# When author.#Kubernetes is empty
+exec holos cue export --expression holos --out=yaml ./components/empty
+cmp stdout want.txt
+
+-- components/empty/empty.cue --
+package holos
+
+Kubernetes: #Kubernetes & {}
+holos: Kubernetes.BuildPlan
+-- want.txt --
+kind: BuildPlan
+apiVersion: v1alpha5
+metadata:
+  name: no-name
+spec:
+  artifacts:
+    - artifact: components/no-name/no-name.gen.yaml
+      generators:
+        - kind: Resources
+          output: resources.gen.yaml
+          resources: {}
+      transformers:
+        - kind: Kustomize
+          inputs:
+            - resources.gen.yaml
+          output: components/no-name/no-name.gen.yaml
+          kustomize:
+            kustomization:
+              labels:
+                - includeSelectors: false
+                  pairs: {}
+              resources:
+                - resources.gen.yaml
+              kind: Kustomization
+              apiVersion: kustomize.config.k8s.io/v1beta1
+source:
+  component:
+    name: no-name
+    path: no-path
+    parameters: {}

doc/md.archive/guides-v1alpha4/helm.mdx

@@ -2291,9 +2291,10 @@ First for prometheus.
 <Tabs groupId="5062EB93-F5AA-4038-9CF8-67A5ECA085FD">
   <TabItem value="command" label="Command">
 ```bash
-cue import -p holos -o- -l '_Helm: Values:' \
-  projects/platform/components/prometheus/vendor/25.27.0/prometheus/values.yaml \
-  > projects/platform/components/prometheus/values.cue
+cue import --package holos \
+  --path '_Helm: Values:' \
+  --outfile projects/platform/components/prometheus/values.cue \
+  projects/platform/components/prometheus/vendor/25.27.0/prometheus/values.yaml
 ```
   </TabItem>
   <TabItem value="output" label="values.cue">
@@ -3647,9 +3648,10 @@ Then for blackbox.
 <Tabs groupId="843D706B-5BE0-46FE-978F-EA17BC1AD932">
   <TabItem value="command" label="Command">
 ```bash
-cue import -p holos -o- -l '_Helm: Values:' \
-  projects/platform/components/blackbox/vendor/9.0.1/prometheus-blackbox-exporter/values.yaml \
-  > projects/platform/components/blackbox/values.cue
+cue import --package holos \
+  --path '_Helm: Values:' \
+  --outfile projects/platform/components/blackbox/values.cue
+  projects/platform/components/blackbox/vendor/9.0.1/prometheus-blackbox-exporter/values.yaml
 ```
   </TabItem>
   <TabItem value="output" label="values.cue">
@@ -4310,11 +4312,10 @@ git diff
          - __address__
          target_label: __param_target
 -      - replacement: blackbox
-+      - replacement: blackbox:6115
++      - replacement: blackbox:9115
          target_label: __address__
        - source_labels:
          - __param_target
-
 ```
   </TabItem>
 </Tabs>
@@ -4578,9 +4579,10 @@ _Kustomize.BuildPlan
 
 // https://github.com/mccutchen/go-httpbin/blob/v2.15.0/kustomize/README.md
 _Kustomize: #Kustomize & {
-	KustomizeConfig: Resources: "github.com/mccutchen/go-httpbin/kustomize": _
+	KustomizeConfig: Files: "resources.yaml": _
 	KustomizeConfig: Kustomization: {
 		commonLabels: "app.kubernetes.io/name": "httpbin"
+		images: [{name: "mccutchen/go-httpbin"}]
 		_patches: probe: {
 			target: kind: "Service"
 			target: name: "httpbin"
@@ -4593,6 +4595,55 @@ _Kustomize: #Kustomize & {
 		patches: [for x in _patches {x}]
 	}
 }
+```
+  </TabItem>
+  <TabItem value="projects/platform/components/httpbin/resources.yaml" label="resources.yaml">
+Add a plain `resources.yaml` file containing resources for kustomize to process.
+:::important
+Holos knows this file is part of the BuildPlan from the `KustomizeConfig:
+Files: "resources.yaml": _` line in the Component.
+:::
+```bash
+mkdir -p projects/platform/components/httpbin
+touch projects/platform/components/httpbin/resources.yaml
+```
+```yaml showLineNumbers
+# https://github.com/mccutchen/go-httpbin/blob/v2.15.0/kustomize/resources.yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: httpbin
+spec:
+  template:
+    spec:
+      containers:
+        - name: httpbin
+          image: mccutchen/go-httpbin
+          ports:
+            - name: http
+              containerPort: 8080
+              protocol: TCP
+          livenessProbe:
+            httpGet:
+              path: /status/200
+              port: http
+          readinessProbe:
+            httpGet:
+              path: /status/200
+              port: http
+          resources: {}
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: httpbin
+spec:
+  ports:
+    - port: 80
+      targetPort: http
+      protocol: TCP
+      name: http
+      appProtocol: http
 ```
   </TabItem>
 </Tabs>

doc/md.archive/guides-v1alpha4/quickstart.mdx

@@ -326,35 +326,34 @@ like this.
 
 ```mermaid
 ---
-title: Figure 1 - Render Pipeline
+title: Figure 1 - v1alpha4 Rendered Manifest Pipeline
 ---
 graph LR
-    PS[<a href="/docs/api/author/v1alpha3/#Platform">Platform</a>]
-    HC[<a href="/docs/api/author/v1alpha3/#ComponentFields">Components</a>]
-    BP[<a href="/docs/api/core/v1alpha3#BuildPlan">BuildPlan</a>]
+    Platform[<a href="/docs/api/author/v1alpha4/#Platform">Platform</a>]
+    Component[<a href="/docs/api/author/v1alpha4/#ComponentConfig">Components</a>]
 
-    H[<a href="/docs/api/author/v1alpha3/#Helm">Helm</a>]
-    K[<a href="/docs/api/author/v1alpha3/#Kustomize">Kustomize</a>]
-    O[<a href="/docs/api/author/v1alpha3/#Kubernetes">Kubernetes</a>]
+    Helm[<a href="/docs/api/author/v1alpha4/#Helm">Helm</a>]
+    Kustomize[<a href="/docs/api/author/v1alpha4/#Kustomize">Kustomize</a>]
+    Kubernetes[<a href="/docs/api/author/v1alpha4/#Kubernetes">Kubernetes</a>]
 
-    P[<a href="/docs/api/core/v1alpha3#Kustomize">Kustomize</a>]
-    Y[Kubernetes <br/>Resources]
-    G[GitOps <br/>Resource]
-    FS[Local Files]
+    BuildPlan[<a href="/docs/api/core/v1alpha4/#buildplan">BuildPlan</a>]
 
-    C[Kube API Server]
+    ResourcesArtifact[<a href="/docs/api/core/v1alpha4/#artifact">Resources<br/>Artifact</a>]
+    GitOpsArtifact[<a href="/docs/api/core/v1alpha4/#artifact">GitOps<br/>Artifact</a>]
 
-    PS --> HC --> BP
-    BP --> H --> P
-    BP --> K --> P
-    BP --> O --> P
+    Generators[<a href="/docs/api/core/v1alpha4/#generators">Generators</a>]
+    Transformers[<a href="/docs/api/core/v1alpha4/#transformer">Transformers</a>]
+    Files[Manifest<br/>Files]
 
-    P --> Y --> FS
-    P --> G --> FS
+    Platform --> Component
+    Component --> Helm --> BuildPlan
+    Component --> Kubernetes --> BuildPlan
+    Component --> Kustomize --> BuildPlan
 
-    FS --> ArgoCD --> C
-    FS --> Flux --> C
-    FS --> kubectl --> C
+    BuildPlan --> ResourcesArtifact --> Generators
+    BuildPlan --> GitOpsArtifact --> Generators
+
+    Generators --> Transformers --> Files
 ```
 
 ### Why do we render the platform? {#why-render-the-platform}

doc/md.archive/introduction.md

@@ -0,0 +1,52 @@
+---
+description: Introduction
+---
+
+# Introduction
+
+Welcome to Holos.  Holos is an open source tool to manage software development
+platforms safely, easily, and consistently.  We built Holos to help engineering
+teams work more efficiently together by empowering them to build golden paths
+and paved roads for other teams to leverage for quicker delivery.
+
+## Documentation
+
+- [Guides] are organized into example use-cases of how Holos helps engineering
+teams at the fictional Bank of Holos deliver business value on the bank's
+platform.
+- The [API Reference] is a technical reference for when you're writing CUE code to define your platform.
+
+## Backstory
+
+At [Open Infrastructure Services], we've each helped dozens of companies build and operate their software development platforms. During the U.S. presidential election just before the pandemic, our second-largest client, Twitter, experienced a global outage that lasted nearly a full day. We were managing their production configuration system, allowing the core infrastructure team to focus on business-critical objectives. This gave us a front-row seat to the incident.
+
+A close friend and engineer on the team made a trivial one-line change to the firewall configuration. Less than 30 minutes later, everything was down. That change, which passed code review, caused the host firewall to revert to its default state on hundreds of thousands of servers, blocking all connections globally—except for SSH, thankfully. Even a Presidential candidate complained loudly.
+
+This incident forced us to reconsider key issues with Twitter's platform:
+
+1. **Lack of Visibility** - Engineers couldn't foresee the impact of even a small change, making it difficult to assess risks.
+2. **Large Blast Radius** - Small changes affected the entire global fleet in under 30 minutes. There was no way to limit the impact of a single change.
+3. **Incomplete Tooling** - The right processes were in place, but the tooling didn't fully support them. The change was tested and reviewed, but critical information wasn't surfaced in time.
+
+Over the next few years, we built features to address these issues. Meanwhile, I began exploring how these solutions could work in the Kubernetes and cloud-native space.
+
+As Google Cloud partners, we worked with large customers to understand how they built their platforms on Kubernetes. During the pandemic, we built a platform using CNCF projects like ArgoCD, Prometheus Stack, Istio, Cert Manager, and External Secrets Operator, integrating them into a cohesive platform. We started with upstream recommendations—primarily Helm charts—and wrote scripts to integrate each piece into the platform. For example, we passed Helm outputs to Kustomize to add labels or fix bugs, and wrote umbrella charts to add Ingress, HTTPRoute, and ExternalSecret resources.
+
+These scripts served as necessary glue to hold everything together but became difficult to manage across multiple environments, regions, and cloud providers. YAML templates and nested loops created friction, making them hard to troubleshoot. The scripts themselves made it difficult to see what was happening and to fix issues affecting the entire platform.
+
+Still, the scripts had a key advantage: they produced fully rendered manifests in plain text, committed to version control, and applied via ArgoCD. This clarity made troubleshooting easier and reduced errors in production.
+
+Despite the makeshift nature of the scripts, I kept thinking about the "[Why are we templating YAML]?" post on Hacker News. I wanted to replace our scripts and charts with something more robust and easier to maintain—something that addressed Twitter's issues head-on.
+
+I rewrote our scripts and charts using CUE and Go, replacing the glue layer. The result is **Holos**—a tool designed to complement Helm, Kustomize, and Jsonnet, making it easier and safer to define golden paths and paved roads without bespoke scripts or templates.
+
+Thanks for reading. Take Holos for a spin on your local machine with our [Quickstart] guide.
+
+[Guides]: /docs/guides/
+[API Reference]: /docs/api/
+[Quickstart]: /docs/quickstart/
+[CUE]: https://cuelang.org/
+[Author API]: /docs/api/author/
+[Core API]: /docs/api/core/
+[Open Infrastructure Services]: https://openinfrastructure.co/
+[Why are we templating YAML]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=https%3A%2F%2Fleebriggs.co.uk%2Fblog%2F2019%2F02%2F07%2Fwhy-are-we-templating-yaml&sort=byDate&type=story

doc/md.archive/technical-overview.mdx

@@ -0,0 +1,690 @@
+---
+slug: technical-overview
+title: Technical Overview
+description: Learn how Holos makes it easier for platform teams to integrate software into their platform.
+---
+
+<head>
+  <meta property="og:title" content="Technical Overview | Holos" />
+  <meta property="og:image" content="/img/cards/technical-overview.png" />
+</head>
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import Admonition from '@theme/Admonition';
+
+## Overview
+
+Holos makes it easier for platform teams to integrate software into their
+platform.  Existing tools in the Kubernetes ecosystem are narrowly focused on
+application management.  Holos takes a holistic approach, focusing on the broad
+integration layer where applications are joined into the platform.  Holos
+improves cross team collaboration through well defined, typed structures at the
+integration layer.  These definitions provide golden paths for other teams to
+easily integrate their own services into the platform.
+
+{/* truncate */}
+
+## The Problem
+
+Platform teams need to develop and maintain significant glue code to integrate
+Helm charts and YAML manifests into a platform built on Kubernetes.  This glue
+code is often implemented with home grown umbrella charts and scripts.
+Maintaining these charts and scripts takes time and effort that could otherwise
+be spent improving the platform.  The need for each organization to develop and
+maintain this glue code indicates a gap in the Kubernetes ecosystem.  Holos is a
+Go command line tool leveraging [CUE] to fill this gap.
+
+## Key Features
+
+1. Holos enables teams to provide simple definitions for other teams to use as golden paths.
+2. Define integrations in [CUE] with strong type checking.  No more text templates or bash scripts.
+3. Simplify complex integration.  Order does not matter.  Validation is early and quick.
+4. Reuse your existing Helm charts and Kustomize bases.
+5. Implement the [rendered manifests pattern].  Changes are clearly visible platform-wide.
+6. Fully render manifests to plain files.  Use your existing GitOps tools and processes.
+7. Post-process with Kustomize from CUE instead of plain text files.  Customize your Kustomizations.
+8. Mix in resources to Helm charts and Kustomize bases, for example ExternalSecrets.
+9. Render all of Helm, Kustomize, CUE, JSON, and YAML consistently with the same process.
+
+## Rendering Pipeline
+
+```mermaid
+---
+title: Figure 1 - v1alpha4 Rendered Manifest Pipeline
+---
+graph LR
+    Platform[<a href="/docs/api/author/v1alpha4/#Platform">Platform</a>]
+    Component[<a href="/docs/api/author/v1alpha4/#ComponentConfig">Components</a>]
+
+    Helm[<a href="/docs/api/author/v1alpha4/#Helm">Helm</a>]
+    Kustomize[<a href="/docs/api/author/v1alpha4/#Kustomize">Kustomize</a>]
+    Kubernetes[<a href="/docs/api/author/v1alpha4/#Kubernetes">Kubernetes</a>]
+
+    BuildPlan[<a href="/docs/api/core/v1alpha4/#buildplan">BuildPlan</a>]
+
+    ResourcesArtifact[<a href="/docs/api/core/v1alpha4/#artifact">Resources<br/>Artifact</a>]
+    GitOpsArtifact[<a href="/docs/api/core/v1alpha4/#artifact">GitOps<br/>Artifact</a>]
+
+    Generators[<a href="/docs/api/core/v1alpha4/#generators">Generators</a>]
+    Transformers[<a href="/docs/api/core/v1alpha4/#transformer">Transformers</a>]
+    Files[Manifest<br/>Files]
+
+    Platform --> Component
+    Component --> Helm --> BuildPlan
+    Component --> Kubernetes --> BuildPlan
+    Component --> Kustomize --> BuildPlan
+
+    BuildPlan --> ResourcesArtifact --> Generators
+    BuildPlan --> GitOpsArtifact --> Generators
+
+    Generators --> Transformers --> Files
+```
+
+## Use Case
+
+One of the development teams at the fictional Bank of Holos wants to deploy a
+simple web app for an experimental project they're working on.
+
+The platform team at the bank wants to build a simple golden path for teams to
+provision projects consistently and easily in compliance with the bank's
+policies.
+
+### Platform Team
+
+The platform team builds a golden path for development teams to register their
+project with the platform.  In compliance with bank policy, the platform team
+needs to manage important security resources for each new project.  All of these
+resources can be derived from only 3 pieces of information.
+
+1. The name of the project the dev team is working on.
+2. The name of the team who currently owns the project.
+3. The services, if any, the project is exposing.
+
+The platform team defines a structure for the dev team to register this
+information.  This structure provides the golden path for the dev team.
+
+The development team registers their experimental project, creatively named
+"experiment" by submitting a pull request that contains this information.
+
+<Tabs groupId="EB9C9AF1-F1AA-4189-B746-A5B8E3043F87">
+  <TabItem value="projects/experiment.cue" label="projects/experiment.cue">
+```cue showLineNumbers
+package holos
+
+// The development team registers a project name.
+_Projects: experiment: {
+  // The project owner must be named.
+  Owner: Name: "dev-team"
+  // Expose Service podinfo at https://podinfo.example.com
+  Hostnames: podinfo: Port: 9898
+}
+```
+  </TabItem>
+</Tabs>
+
+The platform team uses these three pieces of information to derive all of the
+platform resources necessary to support the development team.
+
+1. **Namespace** for the project resources.
+2. **RoleBinding** to grant the dev team access to the project namespace.
+3. **SecretStore** which implements the secret management policy for the bank.
+4. **ReferenceGrant** to expose the project services through the Gateway API.
+5. **HTTPRoutes** to expose the project services, if any.
+6. **AppProject** to deploy and manage the project Applications with ArgoCD.
+7. **Common Labels** to ensure every resource is labeled for resource accounting.
+
+Rendering the platform generates fully rendered manifests for all of these
+resources.  These manifests are derived from the three pieces of information the
+dev team provided.
+
+Note the platform team must manage these resources across multiple namespaces.
+The first four reside in the project namespace owned by the dev team.  The
+HTTPRoute and AppProject go into two namespaces managed by the platform team.
+Holos makes it easier for the platform team to organize these resources into
+different components with different owners.
+
+:::important
+Holos supports [CODEOWNERS] by clearly defining the teams responsible for each
+platform component.
+:::
+
+<Tabs groupId="2E46EA1C-B118-44BF-AE20-752E8D1CE131">
+  <TabItem value="command" label="Command">
+```bash
+holos render platform ./platform
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+rendered httproutes for cluster overview in 177.823625ms
+rendered app-projects for cluster overview in 180.946834ms
+rendered projects for cluster overview in 181.98725ms
+rendered namespaces for cluster overview in 182.30725ms
+rendered platform in 182.31075ms
+```
+:::tip
+If you'd like to try this for yourself, `cd` into [examples/tech-overview] and
+render the platform.
+:::
+
+  </TabItem>
+</Tabs>
+
+The fully rendered manifests are written into the `deploy/` directory organized
+by cluster and component for GitOps.
+
+<Tabs groupId="07FBE14E-E9EA-437B-9FA1-C6D8806524AD">
+  <TabItem value="deploy/clusters/local/components/namespaces/namespaces.gen.yaml" label="namespaces">
+```
+cat deploy/clusters/local/components/namespaces/namespaces.gen.yaml
+```
+```yaml showLineNumbers
+apiVersion: v1
+kind: Namespace
+metadata:
+  labels:
+    argocd.argoproj.io/instance: namespaces
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    holos.run/component.name: namespaces
+    kubernetes.io/metadata.name: experiment
+  name: experiment
+```
+  </TabItem>
+  <TabItem value="deploy/clusters/local/components/projects/projects.gen.yaml" label="projects">
+```
+cat deploy/clusters/local/components/projects/projects.gen.yaml
+```
+```yaml showLineNumbers
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  labels:
+    argocd.argoproj.io/instance: projects
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    holos.run/component.name: projects
+  name: admin
+  namespace: experiment
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: admin
+subjects:
+- apiGroup: rbac.authorization.k8s.io
+  kind: Group
+  name: oidc:sg-dev-team@example.com
+---
+apiVersion: external-secrets.io/v1beta1
+kind: SecretStore
+metadata:
+  labels:
+    argocd.argoproj.io/instance: projects
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    holos.run/component.name: projects
+  name: default
+  namespace: experiment
+spec:
+  provider:
+    kubernetes:
+      auth:
+        token:
+          bearerToken:
+            key: token
+            name: eso-reader
+      remoteNamespace: experiment
+      server:
+        caBundle: LS0tLS1CRUd...QVRFLS0tLS0K
+        url: https://management.example.com:6443
+---
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: ReferenceGrant
+metadata:
+  labels:
+    argocd.argoproj.io/instance: projects
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    holos.run/component.name: projects
+  name: istio-ingress
+  namespace: experiment
+spec:
+  from:
+  - group: gateway.networking.k8s.io
+    kind: HTTPRoute
+    namespace: istio-ingress
+  to:
+  - group: ""
+    kind: Service
+```
+  </TabItem>
+  <TabItem value="deploy/clusters/local/components/httproutes/httproutes.gen.yaml" label="httproutes">
+```
+cat deploy/clusters/local/components/httproutes/httproutes.gen.yaml
+```
+```yaml showLineNumbers
+apiVersion: gateway.networking.k8s.io/v1
+kind: HTTPRoute
+metadata:
+  labels:
+    argocd.argoproj.io/instance: httproutes
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    holos.run/component.name: httproutes
+  name: podinfo.example.com
+  namespace: istio-ingress
+spec:
+  hostnames:
+  - podinfo.example.com
+  parentRefs:
+  - name: default
+    namespace: istio-ingress
+  rules:
+  - backendRefs:
+    - name: podinfo
+      namespace: experiment
+      port: 9898
+    matches:
+    - path:
+        type: PathPrefix
+        value: /
+```
+  </TabItem>
+</Tabs>
+
+The rendered manifests are derived from the project registration information by
+definitions implemented by the platform team.  The [Author API] provides a
+[Project] schema, but does not define an implementation.  The platform team
+implements the [Project] schema by adding a `_Projects` struct to manage
+resources according to bank policies.
+
+:::important
+The Author API is intended as a convenient, ergonomic reference for component
+authors.  Definitions **are not** confined to the Author API.
+:::
+
+The following example shows how the platform team wrote the `_Projects`
+definition to derive the Namespace from the project registration provided by the
+dev team.
+
+<Tabs groupId="5732727B-295E-46E1-B851-F8A1C5D7DF88">
+  <TabItem value="projects/platform/components/namespaces/namespaces.cue" label="Namespaces Component">
+```txt
+projects/platform/components/namespaces/namespaces.cue
+```
+```cue showLineNumbers
+package holos
+
+_Kubernetes: #Kubernetes & {
+	Name: "namespaces"
+	Resources: Namespace: _Namespaces
+}
+
+// Produce a kubernetes objects build plan.
+_Kubernetes.BuildPlan
+```
+
+1. This is the namespaces component which manages a collection of Namespace resources derived from the project registration data shown in the second tab.
+2. Line 5 manages a Namespace for each value of the `#Namespaces` struct.  See the second tab for how the platform team defines this structure.
+  </TabItem>
+  <TabItem value="projects/projects.cue" label="Projects Definition">
+```txt
+projects/projects.cue
+```
+```cue showLineNumbers
+package holos
+
+import api "github.com/holos-run/holos/api/author/v1alpha4"
+
+// Projects defines the structure other teams register with to manage project
+// resources.  The platform team defines the schema, development teams provide
+// the values.
+_Projects: api.#Projects & {
+	[NAME=string]: {
+		Name: NAME
+		// The platform team requires the development teams to indicate an owner of
+		// the project.
+		Owner: Name: string
+		// The default value for the owner email address is derived from the owner
+		// name, but development teams can provide a different email address if
+		// needed.
+		Owner: Email: string | *"sg-\(Owner.Name)@\(_Organization.Domain)"
+		// The platform team constrains the project to a single namespace.
+		Namespaces: close({(NAME): Name: NAME})
+		// The platform team constrains the exposed services to the project
+		// namespace.
+		Hostnames: [HOST=string]: {
+			Name:      HOST
+			Namespace: Namespaces[NAME].Name
+			Service:   HOST
+			Port:      number | *80
+		}
+
+		CommonLabels: {
+			"\(_Organization.Domain)/project.name": Name
+			"\(_Organization.Domain)/owner.name":   Owner.Name
+			"\(_Organization.Domain)/owner.email":  Owner.Email
+		}
+	}
+}
+
+for Project in _Projects {
+	// Register project namespaces with the namespaces component.
+	_Namespaces: {
+		for Namespace in Project.Namespaces {
+			(Namespace.Name): metadata: labels: Project.CommonLabels
+		}
+	}
+}
+```
+
+1. On lines 8-35 the platform team derives most fields from the project name (line 9), and the owner name (line 13).  The purpose is to fill in the remaining fields defined by the Author API.
+2. Line 13 The dev team is expected to provide a concrete owner name, indicated by the `string` value.
+3. Line 17 The platform team provides a default value for the email address.  The project team may define a different value.
+4. Line 19 The Author API allows a project to have many namespaces.  The platform team constrains this down to one namespace per project by closing the struct.  The namespace name must be the same as the project name.
+5. Lines 22-27 The platform team derives values for a Gateway API [BackendObjectReference] from the hostname provided by the project team.  These values are used later to build HTTPRoutes to expose their service.
+6. Lines 30-32 Common labels are derived to mix into resources associated with this project.
+7. Lines 37-44 The platform team adds a namespace with common labels for each project to the struct we saw in the first tab.
+
+  </TabItem>
+</Tabs>
+
+The RoleBinding, SecretScore, and ReferenceGrant are managed in the
+[projects](https://github.com/holos-run/bank-of-holos/blob/v0.4.1/examples/tech-overview/projects/platform/components/projects/projects.cue)
+component, similar to the previous namespaces example.
+The HTTPRoute is managed separately in the
+[httproutes](https://github.com/holos-run/bank-of-holos/blob/v0.4.1/examples/tech-overview/projects/platform/components/httproutes/httproutes.cue)
+component.
+
+All components are registered with the platform in the
+[platform](https://github.com/holos-run/bank-of-holos/tree/v0.4.1/examples/tech-overview/platform)
+directory.
+
+:::important
+Multiple components, potentially owned by different teams, derive fully rendered
+resources from the same three project values.  The dev team added these three
+values to the `_Projects` struct.  The platform team wrote the definition to
+integrate software according to bank policies.  CUE powers this _unified_
+platform configuration model.
+:::
+
+:::tip
+Components map 1:1 to ArgoCD Applications or Flux Kustomizations.
+:::
+
+### Development Team
+
+The development team has the platform resources they need, but they still need
+to deploy their container.  The development team submits a pull request adding
+the following two files to deploy their existing Helm chart.
+
+<Tabs groupId="7AD1DDA9-8001-462B-8BE0-D9410EB51233">
+  <TabItem value="projects/experiment/components/podinfo/podinfo.cue" label="Helm Component">
+```txt
+projects/experiment/components/podinfo/podinfo.cue
+```
+```cue showLineNumbers
+package holos
+
+// Produce a helm chart build plan.
+_HelmChart.BuildPlan
+
+_HelmChart: #Helm & {
+	Name: "podinfo"
+	Chart: {
+		version: "6.6.2"
+		repository: {
+			name: "podinfo"
+			url:  "https://stefanprodan.github.io/podinfo"
+		}
+	}
+}
+```
+This file represents a Helm chart component to add to the platform.  The second
+tab registers this component with the platform.
+  </TabItem>
+  <TabItem value="platform/podinfo.cue" label="Component Registration">
+```
+platform/podinfo.cue
+```
+```cue showLineNumbers
+package holos
+
+// Manage the component on every workload Cluster, but not management clusters.
+for Cluster in _Fleets.workload.clusters {
+	_Platform: Components: "\(Cluster.name):podinfo": {
+		name:      "podinfo"
+		component: "projects/experiment/components/podinfo"
+		cluster:   Cluster.name
+		tags: project: "experiment"
+	}
+}
+```
+This file registers the component with the platform.  When the platform is
+rendered the dev team's Helm chart will be rendered on all workload clusters
+across the platform.
+  </TabItem>
+</Tabs>
+
+The project tag links the component to the same field of the `_Projects` struct.
+
+:::important
+You can add your own key=value tags in your platform specification to inject
+values into components.  This feature is useful to reuse one component path for
+several environments or customers.
+:::
+
+Once the dev team's component is registered, rendering the platform will render
+their component.
+
+<Tabs groupId="1BAF7AD2-BBCD-4797-A3A6-55A626732845">
+  <TabItem value="command" label="Command">
+```bash
+holos render platform ./platform
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```txt
+rendered namespaces for cluster overview in 185.64075ms
+rendered app-projects for cluster overview in 186.729292ms
+rendered httproutes for cluster overview in 195.222833ms
+rendered projects for cluster overview in 195.217125ms
+// highlight-next-line
+rendered podinfo for cluster overview in 195.830042ms
+rendered platform in 195.90275ms
+```
+  </TabItem>
+</Tabs>
+
+<Tabs groupId="77BF500B-105A-4AB4-A615-DEC19F501AE1">
+  <TabItem value="command" label="Command">
+```bash
+cat deploy/clusters/local/components/podinfo/podinfo.gen.yaml
+```
+  </TabItem>
+  <TabItem value="output" label="Output">
+```yaml showLineNumbers
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/name: podinfo
+    app.kubernetes.io/version: 6.6.2
+    argocd.argoproj.io/instance: podinfo
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    helm.sh/chart: podinfo-6.6.2
+    holos.run/component.name: podinfo
+  name: podinfo
+spec:
+  ports:
+  - name: http
+    port: 9898
+    protocol: TCP
+    targetPort: http
+  - name: grpc
+    port: 9999
+    protocol: TCP
+    targetPort: grpc
+  selector:
+    app.kubernetes.io/name: podinfo
+    argocd.argoproj.io/instance: podinfo
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    holos.run/component.name: podinfo
+  type: ClusterIP
+---
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  labels:
+    app.kubernetes.io/managed-by: Helm
+    app.kubernetes.io/name: podinfo
+    app.kubernetes.io/version: 6.6.2
+    argocd.argoproj.io/instance: podinfo
+    example.com/owner.email: sg-dev-team@example.com
+    example.com/owner.name: dev-team
+    example.com/project.name: experiment
+    helm.sh/chart: podinfo-6.6.2
+    holos.run/component.name: podinfo
+  name: podinfo
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: podinfo
+      argocd.argoproj.io/instance: podinfo
+      example.com/owner.email: sg-dev-team@example.com
+      example.com/owner.name: dev-team
+      example.com/project.name: experiment
+      holos.run/component.name: podinfo
+  strategy:
+    rollingUpdate:
+      maxUnavailable: 1
+    type: RollingUpdate
+  template:
+    metadata:
+      annotations:
+        prometheus.io/port: "9898"
+        prometheus.io/scrape: "true"
+      labels:
+        app.kubernetes.io/name: podinfo
+        argocd.argoproj.io/instance: podinfo
+        example.com/owner.email: sg-dev-team@example.com
+        example.com/owner.name: dev-team
+        example.com/project.name: experiment
+        holos.run/component.name: podinfo
+    spec:
+      containers:
+      - command:
+        - ./podinfo
+        - --port=9898
+        - --cert-path=/data/cert
+        - --port-metrics=9797
+        - --grpc-port=9999
+        - --grpc-service-name=podinfo
+        - --level=info
+        - --random-delay=false
+        - --random-error=false
+        env:
+        - name: PODINFO_UI_COLOR
+          value: '#34577c'
+        image: ghcr.io/stefanprodan/podinfo:6.6.2
+        imagePullPolicy: IfNotPresent
+        livenessProbe:
+          exec:
+            command:
+            - podcli
+            - check
+            - http
+            - localhost:9898/healthz
+          failureThreshold: 3
+          initialDelaySeconds: 1
+          periodSeconds: 10
+          successThreshold: 1
+          timeoutSeconds: 5
+        name: podinfo
+        ports:
+        - containerPort: 9898
+          name: http
+          protocol: TCP
+        - containerPort: 9797
+          name: http-metrics
+          protocol: TCP
+        - containerPort: 9999
+          name: grpc
+          protocol: TCP
+        readinessProbe:
+          exec:
+            command:
+            - podcli
+            - check
+            - http
+            - localhost:9898/readyz
+          failureThreshold: 3
+          initialDelaySeconds: 1
+          periodSeconds: 10
+          successThreshold: 1
+          timeoutSeconds: 5
+        resources:
+          limits: null
+          requests:
+            cpu: 1m
+            memory: 16Mi
+        volumeMounts:
+        - mountPath: /data
+          name: data
+      terminationGracePeriodSeconds: 30
+      volumes:
+      - emptyDir: {}
+        name: data
+```
+  </TabItem>
+</Tabs>
+
+Note the rendered Helm chart resources have consistent project labels.  The
+platform team added a constraint to the project so all Helm charts are post
+processed with Kustomize to add these common labels.  The platform team
+accomplishes this by adding a constraint in the project directory.  This can be
+seen in
+[schema.cue](https://github.com/holos-run/bank-of-holos/blob/v0.4.1/schema.cue#L35-L38)
+where the platform team configures all component kinds for the platform.
+
+We've covered how the platform team provides a golden path for development teams
+to register their projects by defining a Projects structure.  We've also covered
+how the development team deploys their existing Helm chart onto the platform.
+
+## Support & Resources
+
+1. See our [Quickstart] guide to get started with Holos.
+2. Check out our other [Guides] which cover specific topics.
+3. Refer to the [Author API] when writing components.
+4. Consider the [Core API] if you need to do something more advanced than the Author API supports.
+5. Community and commercial [Support] is available.
+6. [Discussions Forum](https://github.com/holos-run/holos/discussions)
+
+[Support]: /docs/support/
+[Guides]: /docs/guides/
+[API Reference]: /docs/api/
+[Quickstart]: /docs/quickstart/
+[CUE]: https://cuelang.org/
+[Author API]: /docs/api/author/
+[Core API]: /docs/api/core/
+[Open Infrastructure Services]: https://openinfrastructure.co/
+[Why are we templating YAML]: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=https%3A%2F%2Fleebriggs.co.uk%2Fblog%2F2019%2F02%2F07%2Fwhy-are-we-templating-yaml&sort=byDate&type=story
+[Holos]: https://holos.run/
+[Quickstart]: /docs/quickstart/
+[rendered manifests pattern]: https://akuity.io/blog/the-rendered-manifests-pattern/
+[examples/tech-overview]: https://github.com/holos-run/bank-of-holos/tree/v0.2.0/examples/tech-overview
+[BackendObjectReference]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.BackendObjectReference
+[CODEOWNERS]: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
+[Project]: /docs/api/author/v1alpha3/#Project

doc/md/api.mdx

@@ -0,0 +1,10 @@
+---
+slug: api
+description: Schema Reference
+---
+
+import DocCardList from '@theme/DocCardList';
+
+# Schema Reference
+
+<DocCardList />

doc/md/api/author.md

@@ -1,5 +1,175 @@
-import DocCardList from '@theme/DocCardList';
+---
+title: Author Schemas
+description: Standardized schemas for component authors.
+sidebar_position: 200
+---
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
 
-# Author API
 
-<DocCardList />
+```go
+import "github.com/holos-run/holos/api/author/v1alpha5"
+```
+
+Package author contains a standard set of schemas for component authors to generate common [core](<https://holos.run/docs/api/core/>) BuildPlans.
+
+Holos values stability, flexibility, and composition. This package intentionally defines only the minimal necessary set of structures. Component authors are encouraged to define their own structures building on our example [topics](<https://holos.run/docs/topics/>).
+
+The Holos Maintainers may add definitions to this package if the community identifies nearly all users must define the exact same structure. Otherwise, definitions should be added as a customizable example in [topics](<https://holos.run/docs/topics/>).
+
+For example, structures representing a cluster and environment almost always need to be defined. Their definition varies from one organization to the next. Therefore, customizable definitions for a cluster and environment are best maintained in [topics](<https://holos.run/docs/topics/>), not standardized in this package.
+
+## Index
+
+- [type ComponentConfig](<#ComponentConfig>)
+- [type Helm](<#Helm>)
+- [type Kubernetes](<#Kubernetes>)
+- [type Kustomize](<#Kustomize>)
+- [type KustomizeConfig](<#KustomizeConfig>)
+- [type NameLabel](<#NameLabel>)
+- [type Platform](<#Platform>)
+
+
+<a name="ComponentConfig"></a>
+## type ComponentConfig {#ComponentConfig}
+
+ComponentConfig represents the configuration common to all kinds of components for use with the holos render component command. All component kinds may be transformed with [kustomize](<https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/>) configured with the [KustomizeConfig](<#KustomizeConfig>) field.
+
+- [Helm](<#Helm>) charts.
+- [Kubernetes](<#Kubernetes>) resources generated from CUE.
+- [Kustomize](<#Kustomize>) bases.
+
+```go
+type ComponentConfig struct {
+    // Name represents the BuildPlan metadata.name field.  Used to construct the
+    // fully rendered manifest file path.
+    Name string
+    // Path represents the path to the component producing the BuildPlan.
+    Path string
+    // Parameters are useful to reuse a component with various parameters.
+    // Injected as CUE @tag variables.  Parameters with a "holos_" prefix are
+    // reserved for use by the Holos Authors.
+    Parameters map[string]string
+    // OutputBaseDir represents the output base directory used when assembling
+    // artifacts.  Useful to organize components by clusters or other parameters.
+    // For example, holos writes resource manifests to
+    // {WriteTo}/{OutputBaseDir}/components/{Name}/{Name}.gen.yaml
+    OutputBaseDir string `cue:"string | *\"\""`
+
+    // Resources represents kubernetes resources mixed into the rendered manifest.
+    Resources core.Resources
+    // KustomizeConfig represents the configuration kustomize.
+    KustomizeConfig KustomizeConfig
+    // Artifacts represents additional artifacts to mix in.  Useful for adding
+    // GitOps resources.  Each Artifact is unified without modification into the
+    // BuildPlan.
+    Artifacts map[NameLabel]core.Artifact
+}
+```
+
+<a name="Helm"></a>
+## type Helm {#Helm}
+
+Helm assembles a BuildPlan rendering a helm chart. Useful to mix in additional resources from CUE and transform the helm output with kustomize.
+
+```go
+type Helm struct {
+    ComponentConfig `json:",inline"`
+
+    // Chart represents a Helm chart.
+    Chart core.Chart
+    // Values represents data to marshal into a values.yaml for helm.
+    Values core.Values
+    // EnableHooks enables helm hooks when executing the `helm template` command.
+    EnableHooks bool `cue:"true | *false"`
+    // Namespace sets the helm chart namespace flag if provided.
+    Namespace string `json:",omitempty"`
+
+    // BuildPlan represents the derived BuildPlan produced for the holos render
+    // component command.
+    BuildPlan core.BuildPlan
+}
+```
+
+<a name="Kubernetes"></a>
+## type Kubernetes {#Kubernetes}
+
+Kubernetes assembles a BuildPlan containing inline resources exported from CUE.
+
+```go
+type Kubernetes struct {
+    ComponentConfig `json:",inline"`
+
+    // BuildPlan represents the derived BuildPlan produced for the holos render
+    // component command.
+    BuildPlan core.BuildPlan
+}
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize assembles a BuildPlan rendering manifests from a [kustomize](<https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/>) kustomization.
+
+```go
+type Kustomize struct {
+    ComponentConfig `json:",inline"`
+
+    // BuildPlan represents the derived BuildPlan produced for the holos render
+    // component command.
+    BuildPlan core.BuildPlan
+}
+```
+
+<a name="KustomizeConfig"></a>
+## type KustomizeConfig {#KustomizeConfig}
+
+KustomizeConfig represents the configuration for [kustomize](<https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/>) post processing. Use the Files field to mix in plain manifest files located in the component directory. Use the Resources field to mix in manifests from network urls.
+
+```go
+type KustomizeConfig struct {
+    // Kustomization represents the kustomization used to transform resources.
+    // Note the resources field is internally managed from the Files and Resources fields.
+    Kustomization map[string]any `json:",omitempty"`
+    // Files represents files to copy from the component directory for kustomization.
+    Files map[string]struct{ Source string } `cue:"{[NAME=_]: Source: NAME}"`
+    // Resources represents additional entries to included in the resources list.
+    Resources map[string]struct{ Source string } `cue:"{[NAME=_]: Source: NAME}"`
+    // CommonLabels represents common labels added without including selectors.
+    CommonLabels map[string]string
+}
+```
+
+<a name="NameLabel"></a>
+## type NameLabel {#NameLabel}
+
+NameLabel represents the common use case of converting a struct to a list where the name field of each value unifies with the field name of the outer struct.
+
+For example:
+
+```
+S: [NameLabel=string]: name: NameLabel
+S: jeff: _
+S: gary: _
+S: nate: _
+L: [for x in S {x}]
+// L is [{name: "jeff"}, {name: "gary"}, {name: "nate"}]
+```
+
+```go
+type NameLabel string
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform assembles a core Platform in the Resource field for the holos render platform command. Use the Components field to register components with the platform.
+
+```go
+type Platform struct {
+    Name       string
+    Components map[NameLabel]core.Component
+    Resource   core.Platform
+}
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/api/core.md

@@ -1,5 +1,412 @@
-import DocCardList from '@theme/DocCardList';
+---
+title: Core Schemas
+description: BuildPlan defines the holos rendering pipeline.
+sidebar_position: 100
+---
+<!-- Code generated by gomarkdoc. DO NOT EDIT -->
 
-# Core API
 
-<DocCardList />
+```go
+import "github.com/holos-run/holos/api/core/v1alpha5"
+```
+
+Package core contains schemas for a [Platform](<#Platform>) and [BuildPlan](<#BuildPlan>). Holos takes a [Platform](<#Platform>) as input, then iterates over each [Component](<#Component>) to produce a [BuildPlan](<#BuildPlan>). Holos processes the [BuildPlan](<#BuildPlan>) to produce fully rendered manifests, each an [Artifact](<#Artifact>).
+
+## Index
+
+- [type Artifact](<#Artifact>)
+- [type BuildPlan](<#BuildPlan>)
+- [type BuildPlanSource](<#BuildPlanSource>)
+- [type BuildPlanSpec](<#BuildPlanSpec>)
+- [type Chart](<#Chart>)
+- [type Component](<#Component>)
+- [type File](<#File>)
+- [type FileContent](<#FileContent>)
+- [type FileContentMap](<#FileContentMap>)
+- [type FilePath](<#FilePath>)
+- [type Generator](<#Generator>)
+- [type Helm](<#Helm>)
+- [type InternalLabel](<#InternalLabel>)
+- [type Join](<#Join>)
+- [type Kind](<#Kind>)
+- [type Kustomization](<#Kustomization>)
+- [type Kustomize](<#Kustomize>)
+- [type Metadata](<#Metadata>)
+- [type Platform](<#Platform>)
+- [type PlatformSpec](<#PlatformSpec>)
+- [type Repository](<#Repository>)
+- [type Resource](<#Resource>)
+- [type Resources](<#Resources>)
+- [type Transformer](<#Transformer>)
+- [type Values](<#Values>)
+
+
+<a name="Artifact"></a>
+## type Artifact {#Artifact}
+
+Artifact represents one fully rendered manifest produced by a [Transformer](<#Transformer>) sequence, which transforms a [Generator](<#Generator>) collection. A [BuildPlan](<#BuildPlan>) produces an [Artifact](<#Artifact>) collection.
+
+Each Artifact produces one manifest file artifact. Generator Output values are used as Transformer Inputs. The Output field of the final [Transformer](<#Transformer>) should have the same value as the Artifact field.
+
+When there is more than one [Generator](<#Generator>) there must be at least one [Transformer](<#Transformer>) to combine outputs into one Artifact. If there is a single Generator, it may directly produce the Artifact output.
+
+An Artifact is processed concurrently with other artifacts in the same [BuildPlan](<#BuildPlan>). An Artifact should not use an output from another Artifact as an input. Each [Generator](<#Generator>) may also run concurrently. Each [Transformer](<#Transformer>) is executed sequentially starting after all generators have completed.
+
+Output fields are write\-once. It is an error for multiple Generators or Transformers to produce the same Output value within the context of a [BuildPlan](<#BuildPlan>).
+
+```go
+type Artifact struct {
+    Artifact     FilePath      `json:"artifact,omitempty"`
+    Generators   []Generator   `json:"generators,omitempty"`
+    Transformers []Transformer `json:"transformers,omitempty"`
+    Skip         bool          `json:"skip,omitempty"`
+}
+```
+
+<a name="BuildPlan"></a>
+## type BuildPlan {#BuildPlan}
+
+BuildPlan represents an implementation of the [rendered manifest pattern](<https://akuity.io/blog/the-rendered-manifests-pattern>). Holos processes a BuildPlan to produce one or more [Artifact](<#Artifact>) output files. BuildPlan artifact files usually contain Kubernetes manifests, but they may have any content.
+
+A BuildPlan usually produces two artifacts. One artifact contains a manifest of resources. A second artifact contains a GitOps resource to manage the first, usually an ArgoCD Application resource.
+
+Holos uses CUE to construct a BuildPlan. A future enhancement will support user defined executables providing a BuildPlan to Holos in the style of an [external credential provider](<https://github.com/kubernetes/enhancements/blob/313ad8b59c80819659e1fbf0f165230f633f2b22/keps/sig-auth/541-external-credential-providers/README.md>).
+
+```go
+type BuildPlan struct {
+    // Kind represents the type of the resource.
+    Kind string `json:"kind" cue:"\"BuildPlan\""`
+    // APIVersion represents the versioned schema of the resource.
+    APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha5\""`
+    // Metadata represents data about the resource such as the Name.
+    Metadata Metadata `json:"metadata"`
+    // Spec specifies the desired state of the resource.
+    Spec BuildPlanSpec `json:"spec"`
+    // Source reflects the origin of the BuildPlan.
+    Source BuildPlanSource `json:"source,omitempty"`
+}
+```
+
+<a name="BuildPlanSource"></a>
+## type BuildPlanSource {#BuildPlanSource}
+
+BuildPlanSource reflects the origin of a [BuildPlan](<#BuildPlan>). Useful to save a build plan to a file, then re\-generate it without needing to process a [Platform](<#Platform>) component collection.
+
+```go
+type BuildPlanSource struct {
+    // Component reflects the component that produced the build plan.
+    Component Component `json:"component,omitempty"`
+}
+```
+
+<a name="BuildPlanSpec"></a>
+## type BuildPlanSpec {#BuildPlanSpec}
+
+BuildPlanSpec represents the specification of the [BuildPlan](<#BuildPlan>).
+
+```go
+type BuildPlanSpec struct {
+    // Artifacts represents the artifacts for holos to build.
+    Artifacts []Artifact `json:"artifacts"`
+    // Disabled causes the holos cli to disregard the build plan.
+    Disabled bool `json:"disabled,omitempty"`
+}
+```
+
+<a name="Chart"></a>
+## type Chart {#Chart}
+
+Chart represents a [Helm](<#Helm>) Chart.
+
+```go
+type Chart struct {
+    // Name represents the chart name.
+    Name string `json:"name"`
+    // Version represents the chart version.
+    Version string `json:"version"`
+    // Release represents the chart release when executing helm template.
+    Release string `json:"release"`
+    // Repository represents the repository to fetch the chart from.
+    Repository Repository `json:"repository,omitempty"`
+}
+```
+
+<a name="Component"></a>
+## type Component {#Component}
+
+Component represents the complete context necessary to produce a [BuildPlan](<#BuildPlan>) from a path containing parameterized CUE configuration.
+
+```go
+type Component struct {
+    // Name represents the name of the component. Injected as the tag variable
+    // "holos_component_name".
+    Name string `json:"name"`
+    // Path represents the path of the component relative to the platform root.
+    // Injected as the tag variable "holos_component_path".
+    Path string `json:"path"`
+    // WriteTo represents the holos render component --write-to flag.  If empty,
+    // the default value for the --write-to flag is used.
+    WriteTo string `json:"writeTo,omitempty"`
+    // Parameters represent user defined input variables to produce various
+    // [BuildPlan] resources from one component path.  Injected as CUE @tag
+    // variables.  Parameters with a "holos_" prefix are reserved for use by the
+    // Holos Authors.  Multiple environments are a prime example of an input
+    // parameter that should always be user defined, never defined by Holos.
+    Parameters map[string]string `json:"parameters,omitempty"`
+}
+```
+
+<a name="File"></a>
+## type File {#File}
+
+File represents a simple single file copy [Generator](<#Generator>). Useful with a [Kustomize](<#Kustomize>) [Transformer](<#Transformer>) to process plain manifest files stored in the component directory. Multiple File generators may be used to transform multiple resources.
+
+```go
+type File struct {
+    // Source represents a file sub-path relative to the component path.
+    Source FilePath `json:"source"`
+}
+```
+
+<a name="FileContent"></a>
+## type FileContent {#FileContent}
+
+FileContent represents file contents.
+
+```go
+type FileContent string
+```
+
+<a name="FileContentMap"></a>
+## type FileContentMap {#FileContentMap}
+
+FileContentMap represents a mapping of file paths to file contents.
+
+```go
+type FileContentMap map[FilePath]FileContent
+```
+
+<a name="FilePath"></a>
+## type FilePath {#FilePath}
+
+FilePath represents a file path.
+
+```go
+type FilePath string
+```
+
+<a name="Generator"></a>
+## type Generator {#Generator}
+
+Generator generates Kubernetes resources. [Helm](<#Helm>) and [Resources](<#Resources>) are the most commonly used, often paired together to mix\-in resources to an unmodified Helm chart. A simple [File](<#File>) generator is also available for use with the [Kustomize](<#Kustomize>) transformer.
+
+Each Generator in an [Artifact](<#Artifact>) must have a distinct Output value for a [Transformer](<#Transformer>) to reference.
+
+1. [Resources](<#Resources>) \- Generates resources from CUE code.
+2. [Helm](<#Helm>) \- Generates rendered yaml from a [Chart](<#Chart>).
+3. [File](<#File>) \- Generates data by reading a file from the component directory.
+
+```go
+type Generator struct {
+    // Kind represents the kind of generator.  Must be Resources, Helm, or File.
+    Kind string `json:"kind" cue:"\"Resources\" | \"Helm\" | \"File\""`
+    // Output represents a file for a Transformer or Artifact to consume.
+    Output FilePath `json:"output"`
+    // Resources generator. Ignored unless kind is Resources.  Resources are
+    // stored as a two level struct.  The top level key is the Kind of resource,
+    // e.g. Namespace or Deployment.  The second level key is an arbitrary
+    // InternalLabel.  The third level is a map[string]any representing the
+    // Resource.
+    Resources Resources `json:"resources,omitempty"`
+    // Helm generator. Ignored unless kind is Helm.
+    Helm Helm `json:"helm,omitempty"`
+    // File generator. Ignored unless kind is File.
+    File File `json:"file,omitempty"`
+}
+```
+
+<a name="Helm"></a>
+## type Helm {#Helm}
+
+Helm represents a [Chart](<#Chart>) manifest [Generator](<#Generator>).
+
+```go
+type Helm struct {
+    // Chart represents a helm chart to manage.
+    Chart Chart `json:"chart"`
+    // Values represents values for holos to marshal into values.yaml when
+    // rendering the chart.
+    Values Values `json:"values"`
+    // EnableHooks enables helm hooks when executing the `helm template` command.
+    EnableHooks bool `json:"enableHooks,omitempty"`
+    // Namespace represents the helm namespace flag
+    Namespace string `json:"namespace,omitempty"`
+}
+```
+
+<a name="InternalLabel"></a>
+## type InternalLabel {#InternalLabel}
+
+InternalLabel is an arbitrary unique identifier internal to holos itself. The holos cli is expected to never write a InternalLabel value to rendered output files, therefore use a InternalLabel when the identifier must be unique and internal. Defined as a type for clarity and type checking.
+
+```go
+type InternalLabel string
+```
+
+<a name="Join"></a>
+## type Join {#Join}
+
+Join represents a [Transformer](<#Transformer>) using [bytes.Join](<https://pkg.go.dev/bytes#Join>) to concatenate multiple inputs into one output with a separator. Useful for combining output from [Helm](<#Helm>) and [Resources](<#Resources>) together into one [Artifact](<#Artifact>) when [Kustomize](<#Kustomize>) is otherwise unnecessary.
+
+```go
+type Join struct {
+    Separator string `json:"separator" cue:"string | *\"---\\n\""`
+}
+```
+
+<a name="Kind"></a>
+## type Kind {#Kind}
+
+Kind is a discriminator. Defined as a type for clarity and type checking.
+
+```go
+type Kind string
+```
+
+<a name="Kustomization"></a>
+## type Kustomization {#Kustomization}
+
+Kustomization represents a kustomization.yaml file for use with the [Kustomize](<#Kustomize>) [Transformer](<#Transformer>). Untyped to avoid tightly coupling holos to kubectl versions which was a problem for the Flux maintainers. Type checking is expected to happen in CUE against the kubectl version the user prefers.
+
+```go
+type Kustomization map[string]any
+```
+
+<a name="Kustomize"></a>
+## type Kustomize {#Kustomize}
+
+Kustomize represents a kustomization [Transformer](<#Transformer>).
+
+```go
+type Kustomize struct {
+    // Kustomization represents the decoded kustomization.yaml file
+    Kustomization Kustomization `json:"kustomization"`
+    // Files holds file contents for kustomize, e.g. patch files.
+    Files FileContentMap `json:"files,omitempty"`
+}
+```
+
+<a name="Metadata"></a>
+## type Metadata {#Metadata}
+
+Metadata represents data about the resource such as the Name.
+
+```go
+type Metadata struct {
+    // Name represents the resource name.
+    Name string `json:"name"`
+}
+```
+
+<a name="Platform"></a>
+## type Platform {#Platform}
+
+Platform represents a platform to manage. A Platform specifies a [Component](<#Component>) collection and integrates the components together into a holistic platform. Holos iterates over the [Component](<#Component>) collection producing a [BuildPlan](<#BuildPlan>) for each, which holos then executes to render manifests.
+
+Inspect a Platform resource holos would process by executing:
+
+```
+cue export --out yaml ./platform
+```
+
+```go
+type Platform struct {
+    // Kind is a string value representing the resource.
+    Kind string `json:"kind" cue:"\"Platform\""`
+    // APIVersion represents the versioned schema of this resource.
+    APIVersion string `json:"apiVersion" cue:"string | *\"v1alpha5\""`
+    // Metadata represents data about the resource such as the Name.
+    Metadata Metadata `json:"metadata"`
+
+    // Spec represents the platform specification.
+    Spec PlatformSpec `json:"spec"`
+}
+```
+
+<a name="PlatformSpec"></a>
+## type PlatformSpec {#PlatformSpec}
+
+PlatformSpec represents the platform specification.
+
+```go
+type PlatformSpec struct {
+    // Components represents a collection of holos components to manage.
+    Components []Component `json:"components"`
+}
+```
+
+<a name="Repository"></a>
+## type Repository {#Repository}
+
+Repository represents a [Helm](<#Helm>) [Chart](<#Chart>) repository.
+
+```go
+type Repository struct {
+    Name string `json:"name"`
+    URL  string `json:"url"`
+}
+```
+
+<a name="Resource"></a>
+## type Resource {#Resource}
+
+Resource represents one kubernetes api object.
+
+```go
+type Resource map[string]any
+```
+
+<a name="Resources"></a>
+## type Resources {#Resources}
+
+Resources represents Kubernetes resources. Most commonly used to mix resources into the [BuildPlan](<#BuildPlan>) generated from CUE, but may be generated from elsewhere.
+
+```go
+type Resources map[Kind]map[InternalLabel]Resource
+```
+
+<a name="Transformer"></a>
+## type Transformer {#Transformer}
+
+Transformer combines multiple inputs from prior [Generator](<#Generator>) or [Transformer](<#Transformer>) outputs into one output. [Kustomize](<#Kustomize>) is the most commonly used transformer. A simple [Join](<#Join>) is also supported for use with plain manifest files.
+
+1. [Kustomize](<#Kustomize>) \- Patch and transform the output from prior generators or transformers. See [Introduction to Kustomize](<https://kubectl.docs.kubernetes.io/guides/config_management/introduction/>).
+2. [Join](<#Join>) \- Concatenate multiple prior outputs into one output.
+
+```go
+type Transformer struct {
+    // Kind represents the kind of transformer. Must be Kustomize, or Join.
+    Kind string `json:"kind" cue:"\"Kustomize\" | \"Join\""`
+    // Inputs represents the files to transform. The Output of prior Generators
+    // and Transformers.
+    Inputs []FilePath `json:"inputs"`
+    // Output represents a file for a subsequent Transformer or Artifact to
+    // consume.
+    Output FilePath `json:"output"`
+    // Kustomize transformer. Ignored unless kind is Kustomize.
+    Kustomize Kustomize `json:"kustomize,omitempty"`
+    // Join transformer. Ignored unless kind is Join.
+    Join Join `json:"join,omitempty"`
+}
+```
+
+<a name="Values"></a>
+## type Values {#Values}
+
+Values represents [Helm](<#Helm>) Chart values generated from CUE.
+
+```go
+type Values map[string]any
+```
+
+Generated by [gomarkdoc](<https://github.com/princjef/gomarkdoc>)

doc/md/diagrams/render-component-sequence.mdx

@@ -0,0 +1,31 @@
+```mermaid
+---
+title: holos render component
+---
+sequenceDiagram
+  participant HRC as holos<br />render component
+  participant CUE as CUE<br />(embedded)
+  participant G as Generator<br />(e.g. Helm)
+  participant T as Transformer<br />(e.g. Kustomize)
+  participant V as Validator<br />(e.g. CUE)
+  participant M as Manifests
+
+  HRC ->>+ CUE: Get apiVersion
+  HRC ->>+ CUE: Get BuildPlan
+  loop For each Artifact in BuildPlan concurrently
+    loop For each Generator in Artifact concurrently
+        HRC ->>+ G: Generate Config
+        G ->>+ HRC: Config
+    end
+    loop For each Transformer in Artifact sequentially
+        HRC ->>+ T: Transform Config
+        T ->>+ HRC: Config
+    end
+    loop For each Validator in Artifact concurrently
+        HRC ->>+ V: Validate Config
+        V ->>+ HRC: Valid / Invalid
+    end
+    HRC ->>+ M: Write Artifact File
+  end
+  Note over M: Ready for deployment
+```

doc/md/diagrams/render-platform-sequence.mdx

@@ -0,0 +1,22 @@
+```mermaid
+---
+title: holos render platform
+---
+sequenceDiagram
+  participant HRP as holos<br />render platform
+  participant HRC as holos<br />render component
+  participant CUE as CUE<br />(embedded)
+  participant A as Artifacts
+  participant M as Manifests
+  HRP ->>+ CUE: Get apiVersion
+  HRP ->>+ CUE: Get Platform Definition
+  loop For each Component in Platform concurrently
+    HRP ->>+ HRC: Execute
+    HRC ->>+ CUE: Get apiVersion
+    HRC ->>+ CUE: Get BuildPlan
+    HRC ->>+ A: Build Artifacts
+    A ->>+ HRC: Manifests
+    HRC ->>+ M: Write Manifest Files
+  end
+  Note over M: Ready for deployment
+```

doc/md/diagrams/rendering-overview.mdx

@@ -0,0 +1,32 @@
+```mermaid
+---
+title: Rendering Overview
+---
+graph LR
+    Platform[<a href="/docs/api/author/v1alpha4/#Platform">Platform</a>]
+    Component[<a href="/docs/api/author/v1alpha4/#ComponentConfig">Components</a>]
+
+    Helm[<a href="/docs/api/author/v1alpha4/#Helm">Helm</a>]
+    Kustomize[<a href="/docs/api/author/v1alpha4/#Kustomize">Kustomize</a>]
+    Kubernetes[<a href="/docs/api/author/v1alpha4/#Kubernetes">Kubernetes</a>]
+
+    BuildPlan[<a href="/docs/api/core/v1alpha4/#buildplan">BuildPlan</a>]
+
+    ResourcesArtifact[<a href="/docs/api/core/v1alpha4/#artifact">Resources<br/>Artifact</a>]
+    GitOpsArtifact[<a href="/docs/api/core/v1alpha4/#artifact">GitOps<br/>Artifact</a>]
+
+    Generators[<a href="/docs/api/core/v1alpha4/#generators">Generators</a>]
+    Transformers[<a href="/docs/api/core/v1alpha4/#transformer">Transformers</a>]
+    Validators[Validators<br/>TBD]
+    Files[Manifest<br/>Files]
+
+    Platform --> Component
+    Component --> Helm --> BuildPlan
+    Component --> Kubernetes --> BuildPlan
+    Component --> Kustomize --> BuildPlan
+
+    BuildPlan --> ResourcesArtifact --> Generators
+    BuildPlan --> GitOpsArtifact --> Generators
+
+    Generators --> Transformers --> Validators --> Files
+```

doc/md/topics.mdx

@@ -0,0 +1,15 @@
+---
+slug: /topics
+title: Topics
+description: Stand alone topics that often come up when using Holos.
+---
+import DocCardList from '@theme/DocCardList';
+
+# Topics
+
+This section has self-contained articles related to various topics that come up
+when writing platform configuration code with Holos.
+
+---
+
+<DocCardList />

doc/md/topics/component-parameters.mdx

@@ -0,0 +1,12 @@
+---
+description: Re-use components by passing in parameters.
+slug: component-parameters
+sidebar_position: 400
+---
+
+# Component Parameters
+
+Key points:
+
+1. Components can be reused.
+2. The Platform spec can pass user defined parameters to a component.