context init

noetl context init --from-gateway

Bootstrap a context by reading the gateway's runtime contract.

noetl context init <name> --from-gateway <gateway-url> [flags]

This is the single-command alternative to typing out --auth0-domain, --auth0-client-id, --auth0-redirect-uri, and --auth0-audience by hand. The CLI fetches GET <gateway-url>/api/runtime/contract, parses the auth0 block when present, prints what it's about to write, prompts for confirmation, and persists the new context.

Available since noetl v2.16.0 (PR #16).

Required arguments

Flag	Description
<name>	Context name. Replaces any existing context with the same name — back it up first if you're not sure.
--from-gateway=<url>	Gateway URL. Trailing slashes and whitespace are stripped before the contract fetch.

Optional arguments

Flag	Default	Description
--runtime=<mode>	distributed	Default runtime for the new context. local, distributed, or auto.
--yes (alias --non-interactive)	off	Skip the confirmation prompt — useful in CI / scripts.
--set-current	off	Make this the current context after writing.

What gets written

Context field	Source
server_url	The --from-gateway URL, normalised (whitespace + trailing slash stripped).
runtime	--runtime flag value.
auth0_domain	contract.auth0.domain.
auth0_client_id	contract.auth0.client_id.
auth0_redirect_uri	contract.auth0.redirect_uri.
auth0_audience	contract.auth0.audience.

Empty Auth0 fields are written as empty strings, not skipped — so the context's view of "what the gateway said" stays a faithful mirror.

kube_* fields are not set by context init. If you also need a port-forward target, follow up with noetl context update after the init.

Examples

# Interactive — prompts before writing
noetl context init gke-prod --from-gateway https://gateway.acme.com

# Scripted / CI
noetl context init gke-prod \
  --from-gateway https://gateway.acme.com \
  --yes

# Switch to it after creation
noetl context init gke-prod \
  --from-gateway https://gateway.acme.com \
  --set-current

# Local-runtime context bootstrapped from a gateway URL
noetl context init smoke-test \
  --from-gateway http://localhost:8090 \
  --runtime local \
  --yes

What the operator sees

$ noetl context init gke-prod --from-gateway https://gateway.acme.com
Fetching runtime contract from https://gateway.acme.com/api/runtime/contract ...

About to write context 'gke-prod':
  server_url:           https://gateway.acme.com
  runtime:              distributed
  auth0_domain:         acme.us.auth0.com
  auth0_client_id:      Abc123XYZ...
  auth0_redirect_uri:   https://app.acme.com/login
  auth0_audience:       (none)

Proceed? [y/N] y
Wrote context 'gke-prod'.

Older gateways and non-Auth0 deployments

If the gateway image predates the runtime-contract auth0 block, or the deployment doesn't use Auth0, the contract still returns 200 but without an auth0 field. In that case the CLI prints a warning, writes only server_url + runtime, and points to noetl context update for the manual follow-up:

Warning: gateway runtime contract does not carry an ``auth0`` block.
  Either the gateway image is older than v2.10 (no Auth0 exposure)
  or the deployment is configured without Auth0.  Context will be
  created with ``server_url`` only.  Add Auth0 fields manually if needed:
    noetl context update gke-prod --auth0-domain=... --auth0-client-id=...

Why this exists

Before context init --from-gateway, the Auth0 application metadata (client_id, redirect_uri, audience) had to be read out of the SPA build or looked up in the Auth0 dashboard, then typed back into noetl context add. That was both error-prone (one wrong character in client_id → opaque "Invalid request" from Auth0) and required operators to know which Auth0 application the SPA + gateway expect.

The gateway already knows the answer — it's configured via Helm values (env.auth0Domain, env.auth0ClientId, env.auth0RedirectUri, env.auth0Audience) and surfaces them as informational fields on the runtime contract. context init --from-gateway reads them so the CLI and the SPA agree about which Auth0 application to use.

See also

• noetl context add — when you want to type every field yourself.
• noetl context update — fill in kube_* after init, or patch any Auth0 field the gateway returned wrong.
• noetl auth login — log in against the newly bootstrapped context.
• gateway runtime contract — the GET /api/runtime/contract endpoint this command consumes.