Documentation
¶
Index ¶
- Constants
- func Materialize(cmd *cobra.Command, client kukeonv1.Client, flags SourceFlags, scope ScopeVars) (v1beta1.CellDoc, error)
- func NewCellCmd() *cobra.Command
- func PrintCellResult(cmd *cobra.Command, result kukeonv1.CreateCellResult)
- func RegisterSourceFlags(cmd *cobra.Command)
- func ValidateOverrideSymmetry(flags SourceFlags) error
- type MockControllerKey
- type ScopeVars
- type SourceFlags
Constants ¶
const AnnotationSourceCell = "kukeon.io/source-cell"
AnnotationSourceCell is the inert provenance annotation a clone carries, recording the cell it was forked from (epic:cell-identity #1073). Distinct from the load-bearing kukeon.io/config / kukeon.io/blueprint lineage labels: no reconcile or selector path keys off it, DiffCell does not compare it, and it pins no identity — it is debug/grooming metadata only. Stored under the `kukeon.io/` prefix (not the `.kukeon.io` controller-managed suffix) so it reads as cell-authored provenance.
Variables ¶
This section is empty.
Functions ¶
func Materialize ¶ added in v0.6.0
func Materialize( cmd *cobra.Command, client kukeonv1.Client, flags SourceFlags, scope ScopeVars, ) (v1beta1.CellDoc, error)
Materialize resolves the source binding named by flags (--from-blueprint / --from-config / --clone) and returns the fully-finalized CellDoc — name allocated, scope overlaid, provenance + overrides applied — WITHOUT persisting it. `kuke create cell` persists the doc stopped via MaterializeCell; `kuke run` create+starts it via CreateCell then attaches. This single entrypoint is the shared materialization function of epic:cell-identity #1025 (AC#4): the two verbs cannot drift because the materialised doc comes from the same code. The caller is responsible for the existence pre-check + persist (materialiseAndPersist for create cell; CreateCell for run).
func NewCellCmd ¶
func PrintCellResult ¶
func PrintCellResult(cmd *cobra.Command, result kukeonv1.CreateCellResult)
PrintCellResult is exported for testing purposes.
func RegisterSourceFlags ¶ added in v0.6.0
RegisterSourceFlags registers the cell-source flag definitions (--from-blueprint, --from-config, --clone, --param, --param-file, --env, --ignore-disk-pressure), their mutual-exclusion, and their shell-completion funcs on cmd. Both `kuke create cell` and `kuke run` call it so the two verbs share one flag-definition set and cannot drift (epic:cell-identity #1025).
It deliberately does NOT call viper.BindPFlag: viper is a process-global singleton and two commands binding the same key would race (last-registered wins). `kuke create cell` adds its own KUKE_CREATE_CELL_* binds after calling this (for env-var fallback); `kuke run` reads the flags directly via cmd.Flags(). Scope flags (--realm/--space/--stack) are NOT registered here — they bind command-specific viper keys and each command owns its own.
func ValidateOverrideSymmetry ¶ added in v0.6.0
func ValidateOverrideSymmetry(flags SourceFlags) error
ValidateOverrideSymmetry enforces the per-path --param/--env override symmetry shared by `kuke create cell` and `kuke run` (epic:cell-identity #1023/#1025):
- --param/--param-file are rejected with --from-config (a CellConfig carries its own spec.values);
- --env is rejected with --from-blueprint (its symmetric counterpart — materialise from a Config to layer env overrides).
The clone source kind carries its own per-lineage variants of these checks (cloneFromConfig / cloneFromBlueprint) because the rejected flag depends on the source cell's recorded bindingKind, not on a CLI flag — so this validator is a no-op for clone. Materialize calls it up front, which is why `kuke run` (which feeds Materialize a SourceFlags it built itself) inherits the same rules without re-implementing them.
Types ¶
type MockControllerKey ¶
type MockControllerKey struct{}
MockControllerKey is used to inject a mock kukeonv1.Client via context in tests.
type ScopeVars ¶ added in v0.6.0
ScopeVars names the command-specific scope viper Vars the materialize path reads to resolve binding-lookup scope. An unset --space/--stack defaults to the var's "default" (issue #1156) so the lookup hits the full default scope; a realm-scoped Blueprint/Config stays reachable via an explicit empty `--space "" --stack ""`. `kuke create cell` passes its KUKE_CREATE_CELL_* vars; `kuke run` passes its KUKE_RUN_* vars. Threading the Vars in (rather than hard-coding KUKE_CREATE_CELL_*) is what lets the two verbs share one Materialize entrypoint without colliding on a global viper key (epic:cell-identity #1025).
type SourceFlags ¶ added in v0.6.0
type SourceFlags struct {
Name string
Realm string
Space string
Stack string
BlueprintName string
ConfigName string
// CloneSource is the source cell name passed via `--clone <src>` (the
// third source kind, epic:cell-identity #1073). When set, the cell is
// forked from the source cell's Spec.Provenance rather than resolved from a
// Blueprint/Config named on the CLI.
CloneSource string
ParamArgs []string
ParamFile string
// EnvArgs holds the validated `--env KEY=VALUE` per-cell overrides. Valid
// with --from-config only (parity with --param on --from-blueprint); baked
// into the attachable container's env and recorded in
// Spec.Provenance.EnvOverrides. Issue #1023.
EnvArgs []string
// IgnoreDiskPressure threads `--ignore-disk-pressure` onto the
// transport-only Spec.IgnoreDiskPressure field so the daemon's
// CreateCell guard is bypassed for this invocation. Issue #1035.
IgnoreDiskPressure bool
}
SourceFlags is the validated bundle of source-flag values the materialize path consumes. It is shared between `kuke create cell` (which persists the materialised doc stopped via MaterializeCell) and `kuke run` (which create+starts it via CreateCell then attaches) — the two verbs build a SourceFlags from their own flag surfaces and feed it to the single Materialize entrypoint so the materialisation cannot drift (epic:cell-identity #1025, AC#4). Fields are exported so the run package can populate them.
Source Files