Honor [__settings__].default_profile in api, bundle, and auth token#5214
Open
janniklasrose wants to merge 7 commits into
Open
Honor [__settings__].default_profile in api, bundle, and auth token#5214janniklasrose wants to merge 7 commits into
janniklasrose wants to merge 7 commits into
Conversation
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
force-pushed
the
janniklasrose/auth-default-profile
branch
from
b86d7bb to
a606de7
Compare
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
simonfaltum
approved these changes
May 8, 2026
Member
simonfaltum
left a comment
simonfaltum
left a comment
There was a problem hiding this comment.
Looks good. Sync'ed with Jan on a nit comment on slack
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
The CLI-only default_profile setting was previously consulted only on MustWorkspaceClient / MustAccountClient paths. `databricks api`, bundle commands without an explicit workspace.host, and `databricks auth token` all silently ignored it. Promote the resolution logic to a shared helper (databrickscfg.ResolveDefaultProfile) and apply it from each affected command. For bundle commands, fall back to default_profile only when the bundle does not pin its own workspace.host or workspace.profile — otherwise applying it could silently route the user to a profile that points at a different host than the bundle expects. Co-authored-by: Isaac
- Changelog now notes that DATABRICKS_HOST still takes precedence over default_profile for `databricks auth token` (matches resolveNoArgsToken Step 1). - Switch the auth token acceptance fixture from https://myworkspace.cloud.databricks.com to https://myworkspace.test per the repo's RFC 2606 convention; same for the secondary "other" profile in that file. Avoids reintroducing DNS/network flakiness. Co-authored-by: Isaac
When a bundle declares workspace.profile but no workspace.host and the user has [__settings__].default_profile set, the bundle's pinned profile must win. configureProfile's guard (Workspace.Profile == "") covers this case but had no test — verified by temporarily removing the guard, which flipped the asserted profile from PROFILE-2 to PROFILE-1. Co-authored-by: Isaac
The previous unit test for the Workspace.Profile == "" guard sat alongside other configureProfile unit tests, but per .agent/rules/testing.md, cmd/... behavior is a strong candidate for acceptance tests, and the existing acceptance/auth/bundle_default_profile/ already covers the related host-empty guard end-to-end. Extending it keeps the related cases together. The new sub-case spawns a child bundle directory with workspace.profile pinned and asserts the bundle's profile (not [__settings__].default_profile) is what gets used. Co-authored-by: Isaac
sethome exported HOME (and USERPROFILE) as the relative path the caller passed in (typically "./home"). The SDK expands `~/.databrickscfg` against $HOME at lookup time, so the moment a test cd's into a child directory, the cfg "disappears": helpers like databrickscfg.GetConfiguredDefaultProfile silently return "" because the relative path no longer points at a real file. That made it easy to write tests that look like they exercise default_profile resolution but actually only succeed because the cfg lookup short-circuits. Resolve $1 to an absolute path with `cd && pwd` (portable on macOS/Linux/Windows-MSYS) before exporting. With this fix, the acceptance/auth/bundle_default_profile "workspace.profile pinned" sub-case correctly fails when the Workspace.Profile == "" guard in cmd/root/bundle.go configureProfile is removed; previously it passed either way. Output for the same directory's "Bundle with workspace.host" sub-case also changes: with the cfg now reachable from the bundle subdir, the SDK's host-based lookup finds the matching profile and validate succeeds instead of failing with "default auth: cannot configure default credentials". Co-authored-by: Isaac
janniklasrose
force-pushed
the
janniklasrose/auth-default-profile
branch
from
8351385 to
81d9297
Compare
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
81d9297 changed sethome to export an absolute HOME so the SDK can locate ~/.databrickscfg after a test cd's. The SDK now reports paths relative to the absolute HOME, which surfaces in user-visible output as [TEST_TMP_DIR]/home/.databrickscfg (or [HOME]/.zshrc where the test registers a HOME replacement). The four committed outputs predated the fix and still expected the relative ./home form; regenerated with ./task test-update. Co-authored-by: Isaac
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
The previous fix resolved $home with `cd && pwd` to give HOME and USERPROFILE an absolute path. On Git Bash (MSYS), plain `pwd` returns Unix-style /c/... paths that the native Windows Go binary can't open, so the SDK silently fails to load ~/.databrickscfg and tests like cmd/api/default-profile (no auth resolves) and cmd/api/workspace-id-none (profile not read; SDK back-fills WorkspaceID from host metadata) fail on Windows only. Use `pwd -W` for USERPROFILE on MSYS/Cygwin to emit the mixed C:/... form Windows file APIs accept. HOME keeps the Unix-style path bash itself wants. Co-authored-by: Isaac
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
janniklasrose
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
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.
Changes
[__settings__].default_profileis a CLI-level fallback for the activeprofile that the SDK does not know about. Until now it was consulted only
on the
MustWorkspaceClient/MustAccountClient/MustAnyClientpaths. Several command surfaces silently ignored it:
databricks api {get,post,...}built its own*config.Configand onlyhonored
--profile.databricks bundle,databricks pipelines) read theprofile only from
--profile/DATABRICKS_CONFIG_PROFILE.databricks auth token(no positional, no flags, no env) jumpedstraight to the interactive picker.
This PR promotes the resolution logic to
databrickscfg.ResolveDefaultProfileand applies it from each affected command:
cmd/api/api.go:--profileflag →DATABRICKS_CONFIG_PROFILEenv →default_profile, then hand off to the SDK.cmd/root/bundle.go(configureProfile): falls back todefault_profileonly when the bundle declares noworkspace.hostandno
workspace.profile. The host-empty guard preserves SDK host-basedresolution when the bundle pins its own host.
cmd/auth/token.go(resolveNoArgsToken): inserts a Step 2.5 betweenthe env-var check and the interactive picker. If the named profile
doesn't exist, falls through to the picker (advisory, not fatal).
Why
Users reasonably expect "I set my default to
tmp— every CLI invocationshould default to
tmp." The previous behavior was inconsistent acrosscommand surfaces and surprised users.
The bundle host-empty guard is the only subtle bit worth flagging:
applying
default_profilebefore the SDK sees a bundle's pinnedworkspace.hostcould silently route the user to a profile pointing at adifferent host. The guard lets the existing multi-profile-match path
(
resolveProfileAmbiguity) handle host conflicts as before.Tests
libs/databrickscfg/ops_test.go: matrix tests forResolveDefaultProfile(file present/absent, settings present/absent, parse error, reserved
__settings__self-reference, default home-file lookup).cmd/root/bundle_test.go: fourTestBundleConfigureWithDefaultProfile_*unit tests covering the positive case,
--profileoverride,DATABRICKS_CONFIG_PROFILEoverride, and the bundle-host-wins guard.Acceptance tests:
acceptance/cmd/api/default-profile/acceptance/auth/bundle_default_profile/(with a bundle-with-hostsub-case)
acceptance/cmd/auth/token/default-profile/(with a missing-defaultfall-through case)
Each new acceptance test covers the positive case (
default_profilehonored) and the negative case (
--profileoverrides).This PR was written by Claude Code.