Fix missing git info for bundles deployed from the new type of in-workspace Git folder - #5709
Fix missing git info for bundles deployed from the new type of in-workspace Git folder#5709ilyakuz-db wants to merge 1 commit into
Conversation
Approval status: pending
|
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
GitHub Actions
Inactive
Integration test reportCommit: 0ff1054
8 interesting tests: 4 SKIP, 3 KNOWN, 1 RECOVERED
Top 3 slowest tests (at least 2 minutes):
|
| result.CurrentBranch = gi.Branch | ||
| result.WorktreeRoot = fixedPath | ||
| } else { | ||
| if gi == nil { |
There was a problem hiding this comment.
what happens in the new Git folders case? Does the CLI successfully read GitInfo from the local .git? Can we add some acceptance test coverage for all three cases (new git, classic repo, and vanilla). You can mock the API endpoints.
There was a problem hiding this comment.
On DBR this code never read locally, see this guard
Line 56 in 804d517
That also make it harder to test with acceptance tests as we can't properly mock the environment
There was a problem hiding this comment.
I added some unit tests
There was a problem hiding this comment.
With new git folders API returns only gitInfo.ID
See example
🔴 workspace/get-status doesn't return git provenance for git-in-data-plane folders
Same repo (github.com/databricks/bundle-examples), same path, two workspaces — different
result.
① AWS staging — git-in-DP folder (object_type: DIRECTORY)
Request:
GET /api/2.0/workspace/get-status
?path=/Workspace/Users/<user_name>/bundle-examples
&return_git_info=true
Response:
{
"object_type": "DIRECTORY",
"git_info": {
"id": 2884540697170475,
"path": "/Users/<user_name>/bundle-examples"
}
}
❌ missing branch, head_commit_id, url, provider
…yet the data does exist — same id, Repos API:
GET /api/2.0/repos/2884540697170475
{
"branch": "main",
"head_commit_id": "d53214e177cd372afa03bfc044be9bb94103ba9a",
"url": "https://github.com/databricks/bundle-examples.git",
"provider": "gitHub"
}
✅ full provenance
There was a problem hiding this comment.
There must be a way to read the commit ID? From the .git folders directly maybe as we do locally?
There was a problem hiding this comment.
This can be a followup to this PR - but capturing Git metadata from Git folders is an important usecase? Since DABs in the workspace is supported there?
There was a problem hiding this comment.
This can be a followup to this PR - but capturing Git metadata from Git folders is an important usecase? Since DABs in the workspace is supported there?
It's important — and this PR already covers it, so it doesn't need to be a followup. To clarify the scope:
- This only affects bundles deployed from the workspace. Local and CI/CD deploys are unaffected — they read .git directly
- We already supported two object types: classic Repos and Git folders. Both return the full git_info inline from Workspace get-status API, so they work correctly today
- The gap is a new Private Preview feature, Git in Dataplane. Objects created with that flag don't return a full git_info from get-status — only git_info.id (the repo id) — and there's no .git directory to read on the Dataplane either
- This PR handles that case: it takes the id and calls the Repos API (GET /api/2.0/repos/{id}) to recover branch/commit/url. So Git metadata ends up captured for all of them
There was a problem hiding this comment.
I'll check if it's possible to add acceptance test using RunOnDbr
GitHub Actions
Inactive
GitHub Actions
Inactive
ilyakuz-db
changed the title
1768cae to
f10136d
Compare
The new type of in-workspace Git folder returns only id+path from get-status, so bundles deployed from one recorded empty git provenance. These folders expose a readable .git on the /Workspace FUSE mount, so FetchRepositoryInfo now reads provenance from disk when a .git is reachable and falls back to the existing get-status path otherwise, which still covers classic Repos and older Git folders. Co-authored-by: Isaac
f10136d to
0ff1054
Compare
3 participants
Changes
The new type of in-workspace Git folder returns only
idandpathfromget-status?return_git_info=true(no url/branch/commit), so bundles deployed from one recorded empty git provenance. Classic Repos and existing workspace Git folders return full git info inline and were not affected.These folders do expose a real, readable
.giton the/WorkspaceFUSE mount, soFetchRepositoryInfonow reads provenance from disk when a.gitis reachable, and takes the existingget-statuspath otherwise. No new API call is added.Why
The
.gitcheck is astatwalk-up — the same one the on-disk reader already does — so guarding with it is free: a fraction of a millisecond, against ~80ms forget-status. Reading the folder's own.gitneeds no extra permissions, and the local check is cheaper than any API-based recovery of the same fields.Verified on Azure dogfood serverless against a real git-in-dataplane folder: provenance is recorded correctly (origin URL, branch, and commit all present, matching the folder's actual git state), and
bundle validatein that folder drops from ~3.2s to ~0.45s.Note that on-disk
.gitreflects the checkout rather than server-side state. For recording what was actually deployed, that is arguably the more accurate source.Tests
libs/git/info_test.go:.gitpresent on a DBR path meansget-statusis not called and provenance comes from disk, including walking up from a subdirectory; a/Workspacepath with no.gitstill uses the API, covering inline git info, a remoteless folder with no origin URL, and a plain directory with no git info at all (empty provenance, no error); plushasDotGititself.acceptance/bundle/git-info: coversbundle.gitend to end. The bundle root carries a hand-built.git, which is readable both locally and on the FUSE mount of a DBR session, so the test runs with one expected output in both environments (Local,Cloud,RunsOnDbr). It asserts full provenance from disk, then removes.gitand asserts provenance degrades to empty without failing.This PR was written by Claude Code.