Uh oh!
There was an error while loading. Please reload this page.
[VPEX] localenv: rename compute-target vocabulary target → compute - #6100
Merged
Conversation
The setup-local --output json result named the resolved compute object "target". Rename it to "compute" so the wire format, the Go model, and the resolver vocabulary all match the invocation-side field name the VS Code extension already adopted (SetupLocalInvocation.target → compute, databricks-vscode#2039). The extension parses the payload with a bare structural cast, so the JSON key must match the model field. The rename is carried through the whole compute-selection layer, not just the wire key, so the field/type/function names no longer drift from the "compute" concept (the extension makes the same move: PythonSetupTargetInfo → PythonSetupComputeInfo): - Result.Target field + json tag → Compute / "compute" - TargetInfo type → ComputeInfo - ResolveTarget function → ResolveCompute - TargetFlags / ValidateTargetFlags → ComputeFlags / ValidateComputeFlags - libs/localenv/target.go(+_test) → compute.go(+_test) Deliberately NOT renamed: - BundleTarget — "target" is first-class bundle vocabulary (databricks.yml targets:, --target), so it is correctly named at that boundary. - ErrNoTarget / E_NO_TARGET — the Go const mirrors the stable wire error-code string; renaming would desync it from the error-code contract. - ComputeClient — already "compute". SchemaVersion stays 1: the command is still hidden with no shipped JSON consumer, so there is no old payload in the wild to distinguish and no compatibility window is needed. It will bump once the command is unveiled and the contract has real consumers. Part of DECO-27794 (CLI side). The extension-side model rename is tracked separately in databricks-vscode. Co-authored-by: Isaac
rugpanovforce-pushed
the
dbconnect/rename-target-compute
branch
from
July 29, 2026 17:11
074c0ce to
42f9da2Comparetarget → computetarget → computeCollaborator
Integration test reportCommit: 4c1cb01
8 interesting tests: 4 RECOVERED, 4 SKIP
Top 3 slowest tests (at least 2 minutes):
|
rclarey
approved these changes
Jul 30, 2026
Comment on lines
+23
to
+26
| // Bump it on any breaking change to the JSON shape once the command is | ||
| // unveiled and the payload has real consumers. The command is still hidden | ||
| // with no shipped JSON consumer, so the "target" → "compute" key rename does | ||
| // not bump this: there is no old payload in the wild to distinguish. |
Contributor
There was a problem hiding this comment.
nit: don't think we need this comment update
ContributorAuthor
There was a problem hiding this comment.
Agreed — that was commit-message justification leaking into a permanent comment. Reverted the SchemaVersion comment to the original two lines.
Rename the four remaining `Target` identifiers the vocabulary rename missed: addTargetFlags → addComputeFlags, and the three Test*Target*Flags/Target* test functions → their Compute* equivalents. Pure identifier renames: no behavior, JSON contract, or public API change. The deliberate carve-outs (BundleTarget, ErrNoTarget/E_NO_TARGET, noTargetMessage, and the natural-language "compute target" prose) are left intact. Co-authored-by: Isaac
rugpanovforce-pushed
the
dbconnect/rename-target-compute
branch
from
July 30, 2026 15:13
5c1269d to
4c1cb01CompareUh oh!
There was an error while loading. Please reload this page.
eng-dev-ecosystem-bot
commented
Jul 30, 2026
Collaborator
Integration test reportCommit: 8100d87
20 interesting tests: 10 FAIL, 5 RECOVERED, 2 flaky, 2 SKIP, 1 KNOWN
Top 50 slowest tests (at least 2 minutes):
|
rugpanov added a commit
to databricks/databricks-vscode
that referenced
this pull request
Aug 3, 2026
*Why* The `compute` field doc comment referenced an internal-only JIRA ticket (DECO-27794), which must not appear in this public repo. *What* Remove the DECO-27794 mention from the comment; keep the public databricks/cli#6100 cross-reference that explains the `target` -> `compute` rename. *Verification* Comment-only change (no behavior). `git grep -niE 'DECO-[0-9]+'` over the PR's changed files now returns nothing. Co-authored-by: Isaac
rugpanov added a commit
to databricks/databricks-vscode
that referenced
this pull request
Aug 3, 2026
…de) (#2066) ## What Extension-side half of the `setup-local --output json` `target` → `compute` rename. Follows the CLI half in databricks/cli#6100. ```diff - "target": { "source": "serverless", "envKey": "serverless/serverless-v5", ... } + "compute": { "source": "serverless", "envKey": "serverless/serverless-v5", ... } ``` - `PythonSetupTargetInfo` → `PythonSetupComputeInfo`; `PythonSetupResult.target?` → `compute?` (inner fields unchanged — only the outer key renames, mirroring #6100's `result.go`). - Golden fixtures (`setupLocalResults.ts`): 3× `target:` → `compute:`, kept verbatim from the CLI acceptance goldens. - Consumers updated: orchestrator (`isLocalEnvironmentReady` / `saveState`), `errorMessages.ts` (`r.compute?.envKey`), and their tests. - Dropped the placeholder TODO on the field. ## Why the extension field name must match the wire key The extension parses the CLI result with a bare structural cast (no field mapping), so the TypeScript field name must equal the JSON key the CLI emits. The fixtures are compile-coupled to the contract type, so this is proven at build time. ## Deliberately NOT renamed - **`E_NO_TARGET` / `ERROR_NO_TARGET`** — mirror the stable wire error-code string, which #6100 keeps. ## Blocked on ⛔ **databricks/cli#6100** (CLI side) must merge first, so the CLI's `--output json` emits `compute` and the acceptance goldens flip. Until then the fixtures here would diverge from the upstream goldens they mirror. schemaVersion stays 1 (command still hidden, no shipped consumer). ## Test `yarn build`, `yarn test:lint`, `yarn test:unit` (415 passing) — all green. This pull request and its description were written by Isaac.
yolocs pushed a commit
to yolocs/dbcli
that referenced
this pull request
Aug 11, 2026
…#5835) ## Changes Unveils the `databricks environments setup-local` command: removes `Hidden: true` from `cmd/environments/sync.go` so it appears in `environments --help` and shell completion, and adds a changelog fragment announcing it. ## Why The command was kept hidden while the feature landed across the VPEX stack and while its constraint-artifact repo was private. `databricks/environments` is now public and the command's source is hardcoded to it (databricks#6136), so the command works end-to-end for users and is ready to expose. ## Tests - `go build` + `golangci-lint` clean on `cmd/environments`. - `./task check-changelog` passes. - `localenv` + `help` acceptance suites pass with no golden changes (`-update` produces no diff): the top-level help lists command *groups* — `environments` is a generated API group and is always shown — and the command's own `--help` golden (`acceptance/localenv/help`) was already captured while hidden. - Manually verified `databricks environments --help` now lists `setup-local`, and end-to-end provisioning against the public repo works (serverless dry-run + real provision, merge into an existing / `bundle init` project). > Note: this branch was rebuilt on current `main`. The original 5 commits predated the `target`→`compute` rename (databricks#6100), the `cmd/localenv`→`cmd/environments` rename, and the hardcoded-source change (databricks#6136); four of them only added acceptance tests that already exist on `main`, and the fifth edited a since-renamed file. The unveil now collapses to this single focused commit. _This PR was written by Claude Code._
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Rename the compute-selection vocabulary from
targettocomputeacross thesetup-locallayer, so the--output jsonresult key, the Go model, and theresolver names all match the invocation-side field the VS Code extension already
adopted (
SetupLocalInvocation.target→compute, databricks-vscode#2039).Why carry it beyond the wire key
The extension parses the CLI result with a bare structural cast, so the JSON key
must match the model field. Renaming only the tag would leave
Result.Compute *TargetInfojson:"compute"— three-way naming drift for one concept. Theextension makes the same full move (
PythonSetupTargetInfo→PythonSetupComputeInfo), so this aligns the whole vocabulary.Renamed
Result.Targetfield + json tag →Compute/"compute"TargetInfotype →ComputeInfoResolveTarget→ResolveComputeTargetFlags/ValidateTargetFlags→ComputeFlags/ValidateComputeFlagslibs/localenv/target.go(+_test) →compute.go(+_test)Deliberately NOT renamed
BundleTarget— "target" is first-class bundle vocabulary (databricks.ymltargets:,--target), correctly named at that boundary.ErrNoTarget/E_NO_TARGET— the Go const mirrors the stable wireerror-code string; renaming would desync it from the error-code contract.
ComputeClient— already "compute".schemaVersion stays 1
Not bumped: the command is still
Hiddenwith no shipped JSON consumer, sothere's no old payload in the wild to distinguish and no compatibility window to
maintain. It will bump once the command is unveiled and the contract has real
consumers. (Confirmed with the ticket owner; drops the ticket's step-3
"tolerate both keys" work for the CLI side.)
Test
Build, unit (
libs/localenv,cmd/environments), acceptance(
serverless-json/constraints-only/json-errorregenerated), lint (0),deadcode — all pass.
Part of DECO-27794 (CLI side). The extension-side model rename
(
PythonSetupResult.target→compute,PythonSetupTargetInfo→PythonSetupComputeInfo, errorMessages/fixtures/tests) is tracked separately indatabricks-vscode.
This pull request and its description were written by Isaac.