Fix repos get/update/delete for Git-CLI-enabled folders by GrantIsEaton · Pull Request #6122 · databricks/cli

GrantIsEaton · 2026-07-31T21:05:08Z

Changes

databricks repos get/update/delete <path> resolves the path argument to a repo ID via the workspace get-status API in repoArgumentToRepoID, then required the returned ObjectType to be exactly REPO. This drops that client-side object-type gate and uses the resolved object ID directly.

Why

Since the Git CLI rollout, Git-CLI-enabled folders are materialized as plain DIRECTORY nodes rather than REPO nodes. As a result get-status now returns ObjectType: DIRECTORY for them, and the strict != REPO check rejected valid repos with:

Error: object at path "/Workspace/Users/.../Testrepo" is not a repo

even though the underlying get repo / update repo / delete repo REST APIs still resolve those object IDs fine. The repos API is the authority on whether the target is a repo, so gating on the object type client-side is both redundant and now incorrect for Git CLI folders.

This was reported by a customer whose repos update/get broke on 2026-07-27 after the Git CLI rollout, and confirmed by the repos API owner ("remove the REPO type enforcement... whether it's a repo is enforced at the API layer anyways").

Tests

Updated acceptance/workspace/repos/get_errors to reflect that a non-repo path is no longer rejected client-side; the repos API returns not-found instead.
The testserver get-status fake now reports repos as DIRECTORY nodes (mirroring the post-rollout backend), so the existing path-based repos acceptance tests (delete_by_path, update) exercise the fix. Confirmed these fail with the old object-type gate restored and pass with it removed.

This pull request and its description were written by Isaac.

repoArgumentToRepoID resolved a path via workspace get-status and then required ObjectType == REPO. Since the Git CLI rollout, Git-CLI-enabled folders are materialized as plain DIRECTORY nodes, so get-status returns DIRECTORY and the gate rejected them with `object at path "..." is not a repo` even though the repos API still resolves their object ID as a repo. Drop the client-side object-type gate and let the repos API be the authority, per the repos API owner's guidance. The testserver now reports repos as DIRECTORY nodes so the path-based repos tests guard the fix. Co-authored-by: Isaac

github-actions · 2026-07-31T21:05:45Z

Waiting for approval

Based on git history, these people are best suited to review:

@pietern -- recent work in libs/testserver/, cmd/workspace/repos/, .nextchanges/cli/
@radakam -- recent work in libs/testserver/, acceptance/workspace/repos/get_errors/
@janniklasrose -- recent work in libs/testserver/, .nextchanges/cli/, acceptance/workspace/repos/get_errors/

Eligible reviewers: @andrewnester, @anton-107, @denik, @lennartkats-db, @renaudhartert-db, @shreyas-goenka, @simonfaltum

_{Suggestions based on git history. See OWNERS for ownership rules.}

GrantIsEaton · 2026-07-31T21:09:35Z

-		info = workspace.ObjectInfo{ObjectType: "REPO", Path: cleaned, ObjectId: repoId}
+		// Git-CLI-enabled repos are materialized as plain DIRECTORY nodes, not
+		// REPO nodes, so get-status reports DIRECTORY for them while the repos
+		// API still resolves the object ID as a repo. This mirrors the backend
+		// behavior that repoArgumentToRepoID must tolerate.
+		info = workspace.ObjectInfo{ObjectType: "DIRECTORY", Path: cleaned, ObjectId: repoId}


yes but control plane git folders still use the Repo object type so i think we should be able to test both behaviors and not just one

Good call — updated get-status so control-plane repos under /Repos still report REPO and only Git-CLI folders elsewhere report DIRECTORY. Added acceptance test git_cli_folder to cover the DIRECTORY path while the existing /Repos tests keep exercising REPO. (b6988cc)

GrantIsEaton · 2026-07-31T21:10:19Z

+	// If the argument cannot be parsed as a repo ID, look it up by path.
+	//
+	// We deliberately don't check oi.ObjectType here. Git-CLI-enabled folders
+	// are materialized as plain DIRECTORY nodes rather than REPO nodes, but the
+	// repos API still accepts their object ID as a repo ID. The repos API is the
+	// authority on whether the target is a repo, so gating on the object type
+	// here would reject valid Git CLI folders.


I dont think we need to state all of this what is it helping?

Trimmed it down to three lines. (b6988cc)

GrantIsEaton · 2026-07-31T21:11:38Z

@@ -0,0 +1 @@
+Fixed `databricks repos get/update/delete` failing with `object at path "..." is not a repo` for Git-CLI-enabled folders, which the workspace API now reports as directories rather than repos.


we should make note that the git cli enabled folders are a preview that can be enabled / disabled and alternatively the user can mitigate by turning off the feature

Added a note that Git CLI is a preview and can be turned off in the workspace admin previews settings as an alternative mitigation. (b6988cc)

- testserver get-status now reports control-plane repos (under /Repos) as REPO and Git-CLI folders elsewhere as DIRECTORY, so both behaviors are covered rather than forcing every repo to DIRECTORY. - Add acceptance test git_cli_folder covering path-based get/update/delete against a DIRECTORY-typed Git CLI folder; the /Repos tests keep exercising the REPO type. - Trim the explanatory comment in repoArgumentToRepoID. - Note in the changelog that Git CLI is a toggleable preview and can be turned off as a mitigation. Co-authored-by: Isaac

The case existed to exercise the client-side `!= REPO` gate. With that gate gone, it only tested that an arbitrary directory id isn't a registered repo, which is not a behavior this change is about. The positive REPO and DIRECTORY path-resolution tests cover the fix. Co-authored-by: Isaac

github-actions · 2026-07-31T21:41:41Z

An authorized user can trigger integration tests manually by following the instructions below:

Trigger:
go/deco-tests-run/cli

Inputs:

PR number: 6122
Commit SHA: cfb1677f3be8cc70dc6ccae646233a5c3431f81b

Checks will be approved automatically on success.

damiangajd-db · 2026-07-31T23:26:26Z

+{
+  "method": "GET",
+  "path": "/.well-known/databricks-config"
+}


Do we need this request?

Agreed it's not needed for the test — nothing here asserts on it, and it's unrelated to the repos behavior under test. But it can't be excluded today.

It's the SDK's host-metadata discovery during config init, so it fires before any command logic runs (the testserver registers a default handler for it at libs/testserver/server.go:314 precisely because otherwise any SDK client against the test server fails with "No handler for URL"). More to the point, request recording is unconditional: recordRequestsCallback in acceptance/internal/prepare_server.go:165 appends every request that hits the server to out.requests.txt, and there's no per-endpoint filter anywhere in that path. The only knob is the RecordRequests boolean in test.toml, which is all-or-nothing for the whole test.

So the choices are keep it, turn off RecordRequests for this test (which loses the request assertions that are the point of the test — proving get-status → repos/{id} still resolves correctly for Git CLI folders), or add filtering to the shared harness. All five existing acceptance/workspace/repos/* snapshots carry the same line, as do ~57 others across the tree, so this file matches the established pattern.

If you'd like the harness to skip discovery/boilerplate endpoints from recordings, that seems worth doing on its own — it'd clean up all ~62 snapshots at once, and the change would be localized to recordRequestsCallback plus a test.toml option. Happy to file or take that separately if you want it; just felt out of scope to bundle into this bugfix.

feel free to use print_requests.py in the script

damiangajd-db · 2026-07-31T23:42:57Z

+		// Control-plane repos (under /Repos) report the REPO object type, while
+		// Git-CLI-enabled folders elsewhere are materialized as plain DIRECTORY
+		// nodes. Both resolve to a valid repo ID via the repos API.
+		objectType := workspace.ObjectTypeRepo
+		if !strings.HasPrefix(cleaned, "/Repos/") {
+			objectType = workspace.ObjectTypeDirectory
+		}


This is a weird fake.

i wasnt entirely sure how else to fake a CP git folder vs DP so i told it just to fake the CP git folder in /Repos/ paths.

zgreen-db · 2026-08-03T21:47:25Z

+		// Control-plane repos (under /Repos) report the REPO object type, while
+		// Git-CLI-enabled folders elsewhere are materialized as plain DIRECTORY
+		// nodes. Both resolve to a valid repo ID via the repos API.


Why determine the object type based on path? Not a big deal really I guess because but maybe a little misleading

Do you have a recommendation for how else is best to distinguish between CP or DP in the fake? (i need to test both behaviors from the fake). The path is my only input parameter.

this seems fine for a testserver as it mimics the backend

janniklasrose · 2026-08-04T10:05:23Z

+{
+  "method": "GET",
+  "path": "/.well-known/databricks-config"
+}


feel free to use print_requests.py in the script

janniklasrose · 2026-08-04T10:09:54Z

+		// Control-plane repos (under /Repos) report the REPO object type, while
+		// Git-CLI-enabled folders elsewhere are materialized as plain DIRECTORY
+		// nodes. Both resolve to a valid repo ID via the repos API.


this seems fine for a testserver as it mimics the backend

janniklasrose · 2026-08-04T10:10:18Z

@@ -0,0 +1,3 @@
+Local = true
+Cloud = false


maybe this should run as a cloud test?

janniklasrose · 2026-08-04T11:09:21Z

@@ -0,0 +1 @@
+Fixed `databricks repos get/update/delete` failing with `object at path "..." is not a repo` for Git-CLI-enabled folders, which the workspace API reports as directories rather than repos. Git CLI is a preview feature; as an alternative mitigation it can be turned off in the workspace admin previews settings.


Don't think we need this in the changelog

Suggested change

Fixed `databricks repos get/update/delete` failing with `object at path "..." is not a repo` for Git-CLI-enabled folders, which the workspace API reports as directories rather than repos. Git CLI is a preview feature; as an alternative mitigation it can be turned off in the workspace admin previews settings.

Fixed `databricks repos get/update/delete` failing with `object at path "..." is not a repo` for Git-CLI-enabled folders, which the workspace API reports as directories rather than repos.

GrantIsEaton commented Jul 31, 2026

View reviewed changes

GrantIsEaton added 2 commits July 31, 2026 21:19

damiangajd-db approved these changes Jul 31, 2026

View reviewed changes

zgreen-db approved these changes Aug 3, 2026

View reviewed changes

janniklasrose reviewed Aug 4, 2026

View reviewed changes

		@@ -0,0 +1 @@
		Fixed `databricks repos get/update/delete` failing with `object at path "..." is not a repo` for Git-CLI-enabled folders, which the workspace API now reports as directories rather than repos.

Uh oh!

Conversation

GrantIsEaton commented Jul 31, 2026

Changes

Why

Tests

Uh oh!

github-actions Bot commented Jul 31, 2026

Waiting for approval

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Jul 31, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GrantIsEaton Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

GrantIsEaton Aug 4, 2026 •

edited

Loading