Update Databricks CLI to v1.12.1

[eng-dev-ecosystem-bot]

Update Databricks CLI to v1.12.1

[rugpanov]

Executive summary — Databricks CLI v1.11.0 → v1.12.1

CLI

• databricks aitools install gains two new install targets: Gemini CLI and Pi (Databricks agent skills installed into each tool's skills directory).
• New databricks environments setup-local command: provisions/updates a local uv .venv matched to a compute target — resolves the target to an environment key, then pins the published Python version, databricks-connect version, and dependency constraints for that key.
• Locally built CLIs (go build, no release flags) now version as 1.12.0-dev+<sha> (the next release with a -dev prerelease) instead of 0.0.0-dev+<sha>, so they sort above the latest release rather than below every release.

Bundles

• New cascade_on_destroy field on the pipeline resource (direct engine): controls whether destroying a pipeline also deletes its datasets — MVs, STs, Views (#5846).
• Fixed bundle.deployment.lock.force being ignored — the --force-lock flag default overwrote the configured value (#6188).
• direct engine job_runs (experimental): now sends a CLI-managed idempotency token on run-now and waits for the run to finish (so its state.result_state is referenceable; a non-success fails the deploy).
• direct: fixed model serving telemetry_config drift (#6106); cli_version in resources.json now records the last writer, not the creator.
• New UC secrets bundle resource (#5861).

Dependency updates

• databricks-sdk-go v0.166.0 → v0.170.0 (#6251); Terraform provider v1.124.0 → v1.126.0 (#6250). These are internal to the bundled binary and transparent to the extension (which uses CLI subcommands and its own TypeScript SDK, not the CLI's Go SDK).

What could be integrated into the VS Code extension experience

1. Graduating the uv Python-setup feature — the headline unblock (flag-flip on existing plumbing, not new code).
The extension already implements the entire uv-native Python-setup flow against databricks environments setup-local: it builds the argv ["environments", "setup-local", "--cluster-id"|"--serverless-version", …, "--constraints-only"?, "--output", "json"] in python-setup/utils/setupLocalArgs.ts:33-49, spawns it via python-setup/gateways/PythonSetupCliClient.ts:136-177 (which lets setup-local shell out to uv as a grandchild), parses the resolved pythonVersion/dbconnectVersion from python-setup/models/PythonSetupResult.ts:50-62, and overlays workspace auth with CliWrapper.getSetupLocalEnvVars (extension.ts:923-926). It resolves versions by delegating to the CLI — there is no independent version lookup.

Crucially, the whole flow ships disabled by default. The comment at extension.ts:874-877 states it plainly: "python-setup ships disabled by default: the CLI's environments setup-local command is available only in custom CLI builds for now" — gated behind databricks.experiments.optInto / PYTHON_SETUP_FEATURE_ID (extension.ts:878-880). v1.12.0 adds environments setup-local to the released CLI, which is exactly the precondition that comment is waiting on. So this bump is what makes graduating the feature from experimental possible.

Honest effort caveat: this is a gating/validation decision, not a build-out — the code path exists. The one thing to verify before flipping it on is that the released command's flag surface (--cluster-id, --serverless-version, --constraints-only, --output json) and JSON shape match what setupLocalArgs.ts/PythonSetupResult.ts expect; the changelog describes the feature but doesn't enumerate flags.

2. Gemini CLI and Pi as aitools install targets — a no-op that's a free user-facing win.
No extension change is required. The agent list is discovered dynamically from databricks aitools list --output json (cli/CliWrapper.ts:714-733), surfaced through AiToolsManager (aitools/AiToolsManager.ts:76-89) and the picker pickAgents → listAgents (aitools/AiToolsCommands.ts:236-289), then passed straight through as --agents <list> to aitoolsInstall (cli/CliWrapper.ts:621-652). There's no hardcoded agent enum (only "cursor" is special-cased). Once this bump lands, Gemini CLI and Pi appear in the agent QuickPick automatically. Worth calling out in release notes; no work.

3. cascade_on_destroy dataset-deletion warning — net-new, low priority.
Today the destroy path passes --auto-approve (cli/CliWrapper.ts:977-983) behind a generic modal — "Are you sure you want to destroy this bundle and all resources associated with it?" (ui/bundle-resource-explorer/BundleCommands.ts:317-326) — with no mention that pipeline datasets (MVs/STs) get dropped. The extension already enumerates those datasets in bundle/BundlePipelinesManager.ts (extractPipelineDatasets, ~461-503), so the plumbing to name what would be deleted exists. Net-new work if pursued (a more specific warning, or surfacing the field), but note cascade_on_destroy is a databricks.yml author-config field, not a CLI flag — so this is marginal and largely an authoring concern, not a deploy-time one.

4. The --force-lock fix (#6188) — effectively transparent, mildly reassuring.
The extension drives force deploy/destroy via the flag itself — ["bundle","deploy",…,"--force-lock","--force"] and ["bundle","destroy",…,"--force-lock"] (cli/CliWrapper.ts:939-945, 977-983), wired to the forceDeployCommand/forceDestroyCommand (ui/bundle-resource-explorer/BundleCommands.ts:174-176, 362-364). The fix concerns the databricks.yml bundle.deployment.lock.force config field being overwritten by the flag default; the extension defines LockClass in bundle/BundleSchema.ts:150-159 but never reads or exposes it. Since the extension uses the flag path, behavior is unchanged — no action needed. The takeaway is only that the flag it relies on continues to behave.

5. Explicit no-ops for the extension:

• Local -dev version string: the mismatch check (utils/PackageJsonUtils.ts:160-180) does exact string equality (actual === metaData.cliVersion) and runs only in dev checkouts (isDevExtension()). A locally built CLI still won't equal the pinned 1.12.1, so the warning fires exactly as before. (Optional, unrelated micro-cleanup: it could semver-parse or recognize -dev builds, but there's no need.)
• direct-engine job_runs, model serving telemetry_config, cli_version in resources.json: the extension reads remote state via bundle summary (bundle/models/BundleRemoteStateModel.ts:170-187), never parses resources.json, and its resource explorer only renders jobs and pipelines (ui/bundle-resource-explorer/types.ts KNOWN_RESOURCE_TYPES). These direct-engine internals are invisible to it.
• UC secrets bundle resource (#5861): secret_scopes exists in BundleSchema.ts but has no tree node in the resource explorer; supporting it would be net-new UI, unrelated to this bump.
• SDK / Terraform provider bumps: internal to the bundled binary; transparent.

Don't forget to re-fetch the bundled CLI after this bump lands (yarn workspace databricks run package:cli:fetch) — bin/ is gitignored, so a stale v1.11.0 binary will otherwise stay in place.

_{🤖 Auto-generated executive summary of the CLI v1.11.0 → v1.12.1 changelog. Integration notes are opportunities, not commitments — verify before acting.}

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/vscode

Inputs:

• PR number: 2109
• Commit SHA: 520d0d5d2144d561d1968137c71876864408c27e

Checks will be approved automatically on success.