sng apply, validate, plan, pull

Available

Deployed and supported. The fields and commands described here are stable within version v1alpha1.

These four commands form the work cycle on the desired state of the current tenant. They require a tenant session (sng tenant use).

Accepted files

PATH is a file or a directory. Default: the current directory.

• .yml and .yaml extensions; other files are ignored.
• Several documents per file, separated by ---.
• Each document must have kind and metadata.name. The kind must be applicable by sng apply.
• metadata only holds name: no tenant (inferred from your session), no label, no annotation. Otherwise: metadata : seul name est permis (<clé> refusé).

sng validate

sng validate [PATH]

Sends the manifests to the API for validation without writing anything: structure, kind schema, consistency rules, allowed domains, quotas. It is the same validation as apply.

validate OK — 3 document(s)

When there is a problem, one line per issue, then an error:

error: App/web: spec.services.db: volumes require replicas <= 1 and strategy recreate
error: SSMSecret/token: spec.rotateDays requires spec.length > 0
Error: validation failed (2 issue(s))

--json: {"valid":false,"issues":[{"kind":"App","name":"web","message":"…"}]}.

sng plan

sng plan [PATH]

Compares the local manifests with the desired state and announces what apply would do, without writing anything.

ACTION     KIND       NAME
create     App        web
update     SSMSecret  db-password
unchanged  App        api

Action	Meaning
create	The manifest does not exist in the desired state yet
update	It exists and its content differs
unchanged	Identical: apply will not touch it

plan does not report manifests present in the desired state but absent from PATH: apply never deletes anything. To delete: sng kind delete.

Without manifests: nothing to plan.

sng apply

sng apply [PATH]

Validates and then writes the manifests to the desired state, and triggers their processing. A manifest identical to the existing one is rewritten as is (no effect).

apply acme — 2 object(s)
  App/web  (web.yml)
  SSMSecret/db-password  (secrets/db-password.yml)

Each line gives the resource (Kind/name) and the file it comes from. Changes are usually taken into account within a minute.

--json: {"uploads":[{"kind":"App","name":"web","source":"web.yml",…}]}.

Once applied, follow the convergence with the kind's command (sng app describe, sng secret describe) or, for other kinds, with the command given in sng kind get.

Reproducible

apply is meant to be replayed, locally as well as in CI: the same directory applied twice gives the same state. Version your manifests in git and make sng apply the deployment step of your pipeline (CI/CD).

An apply interrupted before the end has no effect: no manifest is partially taken into account.

sng pull

sng pull [DIR]

Downloads the entire desired state of the current tenant into DIR (default stackngo), one file per manifest: DIR/<Kind>/<nom>.yml, plus a DIR/stackngo.yaml that records the tenant.

pull acme → stackngo (4 object(s))

stackngo/
├── stackngo.yaml
├── App/
│   ├── api.yml
│   └── web.yml
├── SSMSecret/
│   └── db-password.yml
└── RegistryRepository/
    └── web.yml

This is how you put a hand-built tenant under git, or check what the platform has actually saved. Existing files in DIR are overwritten; those that no longer have a matching manifest are not deleted.

Typical errors

Message	Cause
tenant session required: run sng tenant use NAME	No current tenant: sng tenant use <tenant>
forbidden (no policy of this tenant allows it: see sng tenant policy list)	The session lacks deploy:write (apply) or deploy:read (plan, validate, pull)
unsupported kind …	The kind cannot be applied by apply (reserved kind, or typo)
invalid manifest …	Schema or consistency rule broken; the message names the field
conflict	Name or host already taken, or resource being deleted