Write resource manifests
本頁內容尚未翻譯。
Each manifest describes desired state for one resource. metadata.name identifies it, metadata.namespace selects its scope when supported, and spec contains kind-specific data.
How should I create a starting manifest?
Section titled “How should I create a starting manifest?”Prefer xcsh export <KIND> <NAME> -f exported.yaml for an existing resource. For a new resource, start from a repository example tied to the current catalog. Remove server-managed fields before reuse.
How do I keep a directory deterministic?
Section titled “How do I keep a directory deterministic?”Use one resource per YAML document, stable names, and explicit namespaces. Run xcsh validate -f manifests/ -R so nested files are included intentionally.
Start from the catalog schema for the exact kind and keep one resource per manifest while learning. Set metadata, namespace, and required specification fields explicitly; omit server-owned status and identifiers. Run local validation before any command that contacts the tenant, then run a live diff in the selected context. A clean local parse does not prove authorization, existence, or a safe remote change.