Fix missing git info for bundles deployed from in-workspace Git folders#5709
Fix missing git info for bundles deployed from in-workspace Git folders#5709ilyakuz-db wants to merge 2 commits into
Conversation
Co-authored-by: Isaac
Approval status: pending
|
Co-authored-by: Isaac
ilyakuz-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
ilyakuz-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
ilyakuz-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
ilyakuz-db
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Integration test reportCommit: 804d517
20 interesting tests: 13 SKIP, 7 RECOVERED
Top 6 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
3 participants
Changes
When a bundle is deployed from inside the workspace and its source lives in a Git folder, the CLI reads git provenance from
get-status?return_git_info=true. The new in-workspace Git-folder model (git-in-dataplane) returns onlyidandpaththere (no branch/commit/url), so the CLI recorded empty git info (origin URL, branch, commit).This parses the git folder
idand, when the origin URL is missing, falls back toRepos.GetByRepoIdto fill in branch/commit/url. Classic Repos return these inline from get-status and skip the extra call. A failed lookup degrades to best-effort, matchingFetchRepositoryInfo's existing contract.Why
On dataplanes with the new in-workspace Git folders,
get-statusreturnsgit_info: { id, path }only, while classic Repos return the full object — so in-workspace deploys from a Git folder recorded blank git provenance (including in the deployment metadata service version). The Repos API still returns full provenance for these folders by id. (Reading on-disk.gitis not an option here — workspace Repos don't expose a usable.giton the dataplane, which is why the API path exists.)Tests
Unit tests in
libs/git/info_test.go(testserver +dbr.MockRuntime): new Git folder → provenance recovered via Repos API; classic Repo → Repos API not called; Repos lookup failure → graceful degradation.go test ./libs/git/passes; lint clean.For acceptance tests I can't see proper way to test RN and we can't mock DBR
This PR was written by Claude Code.