Pass DATABRICKS_CLI_PATH to subprocess environment in DatabricksCliAuthProvider#1903
Closed
DM87 wants to merge 1 commit into
Closed
Pass DATABRICKS_CLI_PATH to subprocess environment in DatabricksCliAuthProvider#1903DM87 wants to merge 1 commit into
DM87 wants to merge 1 commit into
Conversation
Contributor
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Contributor
|
Please watch #1908 for the fix |
rugpanov
added a commit
that referenced
this pull request
Jun 16, 2026
…#1910) ## Why - On Windows, `databricks bundle` deploys fail with `databricks CLI not found` because the SDK / Terraform provider can't locate the bundled CLI when running in a subprocess. - The path that was forwarded was extensionless (`bin/databricks`), but the bundled Windows binary is `databricks.exe`. The Go SDK / Terraform provider do a literal file lookup and do **not** auto-append `.exe` the way Windows' `CreateProcess` does — so the lookup fails. - The legacy `.databricks/project.json` persisted the bundled CLI path (`databricksPath`), and `AuthProvider.fromJSON` preferred it over the freshly resolved path. That snapshot is version-pinned and, on Windows, was stored without `.exe`, so it overrode the corrected path during legacy→bundle migration. This builds on #1903 (which adds the `DATABRICKS_CLI_PATH` env var) by also making the path it forwards correct on Windows and not letting a stale persisted path win. ## What - Forward the resolved CLI path to subprocesses via the `DATABRICKS_CLI_PATH` env var so they don't fall back to a `PATH` search (`DatabricksCliAuthProvider.toEnv`). - Make `CliWrapper.cliPath` return the platform-specific binary name: `databricks.exe` on `win32`, `databricks` elsewhere. - In `AuthProvider.fromJSON`, always use the freshly resolved bundled CLI path and ignore the persisted `databricksPath` — it's an extension-managed, version-pinned value that is stale after any upgrade. (`fromSdkConfig` is intentionally left alone, since its `databricksCliPath` comes live from the user's `.databrickscfg`.) - Added explanatory comments at each site. ## Verification - Added unit tests for: the platform-specific binary name, `toEnv()` exposing `DATABRICKS_CLI_PATH`, and `fromJSON` ignoring a stale persisted `databricksPath`. Suite passes in the VS Code test host (14 relevant tests green). - Built the `win32-x64` VSIX and confirmed the bundled `extension/out/extension.js` contains both the env var and the `.exe` path, with `bin/databricks.exe` packaged. This pull request and its description were written by Isaac.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Summary
Fixes #1896
Bundle operations (deploy, validate) fail with
databricks CLI not foundsince v2.10.7 because the spawned CLI subprocess cannot locate itself for token refresh.Root cause
The CLI bump from v0.286.0 to v0.297.2 brought Go SDK v0.126.0, which changed the
databricks-cliauth strategy to invoke the CLI binary (viacli_token_source.go→findDatabricksCli()) instead of refreshing tokens in-process.DatabricksCliAuthProvider.toEnv()setsDATABRICKS_AUTH_TYPE=databricks-clibut never setsDATABRICKS_CLI_PATH. The spawned CLI sees an emptyDatabricksCliPath, falls back to searchingPATH, and fails because the extension'sbin/directory isn't on the system PATH.The in-process SDK config (
_getSdkConfig()) already passesdatabricksCliPath: this.cliPathcorrectly — the subprocess environment just needs the same treatment.Changes
DATABRICKS_CLI_PATH: this.cliPathtotoEnv()inDatabricksCliAuthProviderTest plan