@zuke/az

The well-known resources get-access-token --resource-type accepts.

Settings for az account get-access-token.

The answer is a bearer token, so the command always runs quietly — captured, never streamed — with --output json pinned whatever the settings or the user's config say, and the token is registered with the run's redactor once it returns.

Settings for az account list.

Settings for az account set: make a subscription the default. Name it with the global .subscription(nameOrId), which account set requires.

Settings for az account show: the current (or the given) subscription.

Settings for az acr build: build an image in the registry from a local directory, a git URL or a tarball, and push it.

--build-arg values are visible to the ACR team for debugging, as the CLI warns; pass a credential with secretBuildArg, whose value is also registered with the run's redactor.

Settings for az acr login.

Without exposeToken the CLI logs the local Docker client in itself. With it, the CLI prints a registry refresh token instead — for docker login with the user 00000000-0000-0000-0000-000000000000 — so the command always runs quietly with --output json pinned, and the token is registered with the run's redactor once it returns.

Settings for az acr repository delete: one image, by tag or digest, or a whole repository. The CLI asks for confirmation unless yes is set.

Settings for az acr repository show-tags.

Settings for az aks get-credentials. The credentials go to a file — ~/.kube/config unless file says otherwise. Printing them (--file -) would put a cluster credential in the build log, so a - is refused.

Settings for az aks show.

An Azure container app as a canary platform. Create one with containerAppCanary; hand it to @zuke/canary's c.platform(...).

Exposure is a share of the app's ingress traffic, set exactly, in whole percents.

The part of the canary engine's context the Container Apps platform uses: the rollout's durable state, where the staged revisions are recorded, and the build summary. The engine hands a richer context; this is the narrow view.

How containerAppCanary reaches the app and deploys the candidate, configured through its lambda.

Settings for az containerapp ingress traffic set: the share of traffic each revision — or each label — receives. The weights must add up to 100; the CLI checks.

Settings for az containerapp revision list.

Settings for az containerapp revision activate and deactivate: the app, and the revision to switch.

Settings for az containerapp show. Secrets stay out: --show-secrets is not typed.

Settings for az containerapp update: a new image, environment or scale, which makes a new revision.

Settings for az deployment group create.

Settings for az deployment group show.

The template, parameters and mode a deploying deployment group command shares — create and what-if read them identically. The deployment's --name is optional here; the CLI defaults it to the template file's name.

Settings for az deployment group what-if: what a deployment would change.

How a deployment treats resources the template does not mention (--mode).

The resource types group delete --force-deletion-types accepts.

Settings for az functionapp deployment source config-zip: deploy a zip package to a function app. This is the generally available command; az functionapp deploy is still in preview.

Settings for az group create.

Settings for az group delete. The CLI asks for confirmation unless yes is set — and fails, without a terminal to ask on.

Settings for az group exists, which prints true or false.

Settings for az group show.

The encodings keyvault secret set --encoding accepts for a file.

Settings for az keyvault secret set.

The value comes from a file — read exactly, with its encoding — or from value, which is sent on standard input as --value=@- so it never enters the argv. The CLI strips trailing line breaks from what it reads that way; use a file for a value that must keep them.

Settings for az keyvault secret show.

One row of a Log Analytics answer: TableName, and each column by name.

Settings for az login, for the non-interactive forms a build uses. The interactive browser and device-code forms are left to .command("login").

Exactly one credential is sent: a secret (password), a certificate or a federatedToken for a service principal, or identity for a managed identity. A service principal without one would make the CLI prompt for a password, so it is refused here.

az login reads the global .subscription(...) as the subscription to make the default once it has signed in. Its output lists the account's subscriptions — no credential — so it is not masked.

Settings for az logout.

Settings for az monitor activity-log list: the control-plane events of a subscription, resource group or resource. The CLI returns at most maxEvents — 50 unless told otherwise.

How AzMonitorMetricValueSettings turns the datapoints into one number: the newest, or the sum, average, maximum or minimum of all of them.

The aggregations Azure Monitor computes per interval (--aggregation).

A health check run against a canary, in the shape @zuke/canary's c.analysis(...) accepts: throw to fail it, which rolls the rollout back.

The part of the canary engine's context the analysis uses: the run's redactor, applied to every failure message. The engine hands a richer context; this is the narrow view.

Settings for azureMonitor: the metric or query, the window and the bounds.

The time grains metrics list --interval takes, in ISO 8601 — the form the CLI passes through unchanged. (Its ##h##m shorthand writes a mixed duration such as 1h30m in the wrong order, so it is not offered.)

Settings for az monitor log-analytics query.

Settings for az monitor metrics alert list.

Settings for az monitor metrics alert show: one metric alert rule. The rule's definition, not whether it is firing — that lives in Azure Monitor's alerts, not in the rule.

Settings for az monitor metrics list-definitions: the metrics a resource has.

Settings for az monitor metrics list: a resource's metrics over a time range, one datapoint per interval.

The CLI returns at most top time series per metric — ten unless told otherwise — so a query that splits by a dimension can silently lose series; raise top to cover them.

Settings for AzTasks.metricValue: a metrics list request with exactly one AzMonitorMetricsListSettings.aggregation, and how to read it.

The Azure CLI succeeded but printed something a reader cannot use: output that is not JSON, JSON of an unexpected shape, an empty or multi-line answer where one value was expected, no data where a number was expected, or a capture that was truncated.

The message never quotes the output itself. Several readers return access tokens and secret values, and an error that echoed what the CLI printed would put the secret in the build log it was read to stay out of.

The values the Azure CLI's --output option accepts.

Settings for a command on one named resource in a resource group.

Settings for an az invocation.

Every instance sets three of the CLI's configuration variables in the child's environment, so the CLI never waits on a keypress, installs code, or colours a build log:

- AZURE_EXTENSION_USE_DYNAMIC_INSTALL=no — a command from an extension that is not installed fails, instead of prompting (on a terminal) or silently downloading and installing the extension (without one). The CLI's message does not name the extension — it says the command is misspelled or not recognized by the system and exits 2 — so install what a build needs up front with az extension add --name <name>. - AZURE_CORE_LOGIN_EXPERIENCE_V2=off — an interactive az login does not open its subscription selector. - AZURE_CORE_NO_COLOR=true — no ANSI colour codes in captured output.

Setting them there keeps the argv exactly what the settings say; override any of them with .env({...}). A confirmation prompt (group delete without --yes) is not switched off: on a terminal it asks, without one the CLI fails — call the command's .yes() to confirm in the build.

Runs one prepared az command and returns what the process produced. The default spawns the CLI; a test, or a build that executes the CLI some other way, injects its own with AzSettings.runner. The runner only produces the output: the exit code is judged afterwards exactly as for a spawned process, so a non-zero code still raises a CommandError unless the settings say .noThrow().

The kinds of swap webapp deployment slot swap --action performs.

How a storage command authenticates (--auth-mode).

Settings for az storage blob download.

The account and credential options every storage blob command takes. One credential at most: the CLI reads it from standard input.

Settings for az storage blob upload-batch: upload a directory.

Settings for az storage blob upload.

Typed task functions for the az CLI.

The shape of AzTasks.

A time given as a Date or as a string the CLI parses (ISO 8601).

An analysis that reads an Azure Monitor metric — or a KQL query — over a recent window and fails the canary when any datapoint is out of bounds, or when there is no data, unless AzMonitorAnalysisSettings.missingDataAs says what no data means.

The lambda runs on each check, so it may read resolved parameters, and every failure message — one from the lambda included — passes through the run's redactor.

The artifact types webapp deploy --type accepts.

Settings for az webapp config appsettings set.

Each setting's value is part of the argv, so it is visible in the process table and in the command line the build logs; a credential belongs in Key Vault, referenced with keyVaultReference. A value that starts with @ is otherwise refused, because the CLI would read it from a file. The CLI's answer lists every setting with its value redacted.

Settings for az webapp deployment slot swap: swap a slot with production, or with targetSlot.

Settings for az webapp deploy, the current deploy command (the older webapp deployment source config-zip is deprecated in its favour).

Settings for az webapp show.

The kinds of change what-if --exclude-change-types can leave out.

An Azure container app as a canary platform, for @zuke/canary:

c.platform(containerAppCanary((a) =>
  a.name("api").resourceGroup("rg-prod").image(this.image.value)
    .az((z) => z.subscription("prod"))
))

The lambda runs on every call, so it may read resolved parameters. The app must be in multiple-revision mode, with ingress.

- stage — reads the app (containerapp show); pins all traffic to the serving revision by name (ingress traffic set --revision-weight <stable>=100); deploys the image (containerapp update), which makes the candidate revision; checks it is Provisioned; records the rollout. - expose — ingress traffic set --revision-weight <stable>=<100-n> <candidate>=<n>. - promote — checks the latest revision is still the candidate, then --revision-weight latest=100 when traffic followed the latest revision before (once the candidate is also the newest ready revision), or <candidate>=100 <stable>=0 otherwise. - abort — --revision-weight <stable>=100 <candidate>=0 mid-rollout; run by hand, <stable>=100 to the revision set with .stable(...). A rollback with nothing recorded runs nothing: nothing was staged.

Every call after stage that has its record — expose, promote, and abort mid-rollout — compares the configured app, resource group and az flags with the record, reads the app and checks its resource id (which names the subscription), and refuses on any difference before changing anything. Expose and promote also check that the traffic still goes only to the stable revision and the candidate, and that the candidate is the revision staged. Every command after the check carries --subscription with the subscription the checked id names, so a default subscription that changes in the meantime cannot redirect it. The CLI has no conditional update for ingress traffic, so a change landing between a read and the write that follows it is not caught.