Pass DATABRICKS_CLI_PATH and resolve the platform-specific CLI binary#1910
Merged
Conversation
rugpanov
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
rugpanov
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
*Why*: * On Windows, `databricks bundle` deploys failed with "databricks CLI not found" because the SDK/Terraform provider could not locate the bundled CLI. * The forwarded path was extensionless (`bin/databricks`), but the bundled Windows binary is `databricks.exe`; the Go SDK/Terraform do a literal file lookup and do not auto-append `.exe` the way Windows CreateProcess does. * The legacy project.json persisted the bundled CLI path (`databricksPath`), which `fromJSON` preferred over the freshly resolved one. That snapshot is version-pinned and, on Windows, extensionless, so it overrode the corrected path during legacy-to-bundle migration. *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. * 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`, since it is an extension-managed, version-pinned value that is stale after any upgrade. *Verification:* * Added unit tests for the platform-specific binary name, for toEnv() exposing DATABRICKS_CLI_PATH, and for 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 contains both the env var and the `.exe` path, with `bin/databricks.exe` packaged. Co-authored-by: Isaac
rugpanov
force-pushed
the
fix/databricks-cli-path-windows
branch
from
58d02a4 to
36a4dc1
Compare
rugpanov
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
anton-107
approved these changes
Jun 16, 2026
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. |
rugpanov
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
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.
Why
databricks bundledeploys fail withdatabricks CLI not foundbecause the SDK / Terraform provider can't locate the bundled CLI when running in a subprocess.bin/databricks), but the bundled Windows binary isdatabricks.exe. The Go SDK / Terraform provider do a literal file lookup and do not auto-append.exethe way Windows'CreateProcessdoes — so the lookup fails..databricks/project.jsonpersisted the bundled CLI path (databricksPath), andAuthProvider.fromJSONpreferred 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_PATHenv var) by also making the path it forwards correct on Windows and not letting a stale persisted path win.What
DATABRICKS_CLI_PATHenv var so they don't fall back to aPATHsearch (DatabricksCliAuthProvider.toEnv).CliWrapper.cliPathreturn the platform-specific binary name:databricks.exeonwin32,databrickselsewhere.AuthProvider.fromJSON, always use the freshly resolved bundled CLI path and ignore the persisteddatabricksPath— it's an extension-managed, version-pinned value that is stale after any upgrade. (fromSdkConfigis intentionally left alone, since itsdatabricksCliPathcomes live from the user's.databrickscfg.)Verification
toEnv()exposingDATABRICKS_CLI_PATH, andfromJSONignoring a stale persisteddatabricksPath. Suite passes in the VS Code test host (14 relevant tests green).win32-x64VSIX and confirmed the bundledextension/out/extension.jscontains both the env var and the.exepath, withbin/databricks.exepackaged.This pull request and its description were written by Isaac.