Fix repos get/update/delete for Git-CLI-enabled folders - #6122
Fix repos get/update/delete for Git-CLI-enabled folders#6122GrantIsEaton wants to merge 3 commits into
Conversation
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
Waiting for approvalBased on git history, these people are best suited to review:
Eligible reviewers: Suggestions based on git history. See OWNERS for ownership rules. |
| 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} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
| // 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. |
There was a problem hiding this comment.
I dont think we need to state all of this what is it helping?
| @@ -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. | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
|
An authorized user can trigger integration tests manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
| { | ||
| "method": "GET", | ||
| "path": "/.well-known/databricks-config" | ||
| } |
| // 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 | ||
| } |
2 participants
Changes
databricks repos get/update/delete <path>resolves the path argument to a repo ID via the workspaceget-statusAPI inrepoArgumentToRepoID, then required the returnedObjectTypeto be exactlyREPO. 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
DIRECTORYnodes rather thanREPOnodes. As a resultget-statusnow returnsObjectType: DIRECTORYfor them, and the strict!= REPOcheck rejected valid repos with:even though the underlying
get repo/update repo/delete repoREST 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/getbroke 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
acceptance/workspace/repos/get_errorsto reflect that a non-repo path is no longer rejected client-side; the repos API returns not-found instead.get-statusfake now reports repos asDIRECTORYnodes (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.