pub fn kube_api_version(value: &Value) -> Option<&str>Expand description
Read the top-level apiVersion: string-scalar CRD-group/version axis
of a K8s custom resource YAML document as Option<&str> — the pinned
peer on the CRD-group/version axis to the parametric
kube_root_str_field on the top-level <field> sub-axis surface,
and the accessor-arity peer that closes the two-axis top-level
(apiVersion, kind) discriminator-pair the K8s API-machinery pins as
the load-bearing per-CR-registration coordinates. kube_kind
(89a49a4) closes the accessor arity on the top-level kind: half of
the discriminator pair; kube_api_version closes it on the
top-level apiVersion: half — together the two accessors bracket
the CRD-registration coordinate pair every K8s CR readback at
controller / API-server admission time keys off. Structural mirror
of the sibling closure the sub-metadata.{name, namespace}
coordinate pair already carries at accessor arity (kube_name
c9cdecb + kube_namespace e18297b).
Returns None when either the top-level apiVersion: scalar is
absent or the apiVersion: scalar carries a non-string YAML type —
the same two-way vacuous-None short-circuit the parent
kube_root_str_field closes on the underlying one-hop navigation.
The KUBE_KEY_API_VERSION axis is pinned inside the helper
(unlike the parametric field axis of the underlying
kube_root_str_field) because the K8s CRD registration schema
pins apiVersion as the load-bearing per-CR group/version
discriminator on every CustomResource across every group
(paired with kind for CRD-registration disambiguation) — the
same load-bearing status the sibling kind: discriminator carries
on the sibling top-level scalar-axis that already lifted an
accessor peer under the same discipline. Every readback consumer
downstream (.unwrap(), .expect(...), == Some(...) equality
wraps, .to_string() clone) drives off the same pinned return;
a hypothetical future K8s API-machinery rebrand on the
apiVersion: axis (a hypothetical Server-Side-Apply-driven
per-field-ownership migration under an aliased
group/version scalar pair, a schema-migration to a wrapped
apiVersionV2: scalar under a CRD group’s per-conformance
evolution axis) reaches every caller through one lift, not a
coordinated rewrite across every per-CR CRD-registration
readback site.
The canonical shape 10 emit-side test-harness readback sites across
caixa-flux (4) + caixa-mesh (6) previously
carried inline as the two-token composition
kube_root_str_field(<value>, KUBE_KEY_API_VERSION)around a one-token semantic payload (the readback intent — “what
apiVersion did the emitter write into this CR?”). The lift collapses
the two-token composition — the parametric readback helper, the
pinned CRD-group/version-axis scalar-key argument — onto one
accessor the caller reads as intent (kube_api_version(<value>) —
“what is this K8s CR document’s top-level apiVersion:?”) rather
than a readback → axis-pin two-arg call. Peer accessors for other
top-level discriminators (a hypothetical kube_group accessor for
CRD-group filtering on the pre-/-slash prefix of the same
apiVersion: scalar, a kube_version accessor for the
post-/-slash version suffix on a multi-version migration harness)
land as sibling helpers with their own pinned axis, not as
re-parameterizations of this one.
Structural peer to sibling kube_kind (89a49a4) on the sibling
top-level CRD-discriminator half of the same canonical (apiVersion, kind) coordinate pair: kube_kind closes the accessor arity on
the kind: half; kube_api_version closes it on the
apiVersion: half. Same accessor-arity shape, different pinned
scalar-key on the same navigation depth (root) — together the two
accessors bracket the top-level K8s-CR CRD-registration coordinate
pair every renderer + every test-side per-CR readback path reaches
through, closing the accessor-arity peer-set on the same load-
bearing per-CR discriminator pair the K8s API-machinery threads
through every controller / API-server admission decision.
Sites lifted:
- caixa-flux’s per-emitted-file top-level
apiVersion:readback across the 4 emit-side pins on thecluster_bundlemulti-file sequence —cluster_bundle_helmrelease_uses_lifted_flux_api_version(helmrelease.yaml),cluster_bundle_kustomization_health_check_uses_lifted_flux_api_version(per-entrykustomization.yamlspec.healthChecks[].apiVersionloop),cluster_bundle_gitrepository_uses_lifted_flux_api_version(gitrepository.yaml),cluster_bundle_kustomization_uses_lifted_flux_api_version(kustomization.yaml) — each per-filekube_root_str_field(&parsed, KUBE_KEY_API_VERSION) == Some(FLUX_<CRD>_API_VERSION)lifted-uses pin on the Flux v2 controller-triplet CRD-group/version axis; - caixa-mesh’s per-CNP top-level
apiVersion:readback loop in the two test bodiescilium_network_policies_use_lifted_cilium_api_version+cilium_policy_carries_canonical_kube_skeleton— eachfor p in &policies { assert_eq!(kube_root_str_field(p, KUBE_KEY_API_VERSION), Some(CILIUM_API_VERSION)); }loop over the multi-doc CNP emission; - caixa-mesh’s per-Gateway / per-HTTPRoute top-level
apiVersion:readback across the four test bodiesgateway_carries_canonical_kube_skeleton_without_labels(Gateway),httproute_carries_canonical_kube_skeleton_without_labels(HTTPRoute),gateway_routes_gateway_uses_lifted_gateway_api_api_version(Gateway),gateway_routes_httproute_uses_lifted_gateway_api_api_version(HTTPRoute) — eachfind_by_kind(&docs, <KIND>) → kube_root_str_field(_, KUBE_KEY_API_VERSION) == Some(caixa_core::GATEWAY_API_API_VERSION)chain over the paired-Gateway/HTTPRoute emission.
Every future per-CR apiVersion: readback (the future
per-:politicas CiliumClusterwideEnvoyConfig emitter’s per-CR
CRD-group/version pin, MESH-COMPOSITION §III.2 #3; the future
app-operator’s mesh.pleme.io/v1alpha1/Aplicacao CR
materializer’s per-status CRD-group/version readback, §III.2 #5;
the future M4 cross-cluster fan-out’s per-cluster Flux-triplet
CRD-group/version pin across the .toolkit.fluxcd.io root)
reaches the same pinned accessor by construction, with no
axis-key argument drift and no re-inlined
kube_root_str_field(_, KUBE_KEY_API_VERSION) two-token
composition.