apps: git-back scaffolded apps when init runs inside a Git repo - #6406
Closed
atreyadbrx wants to merge 2 commits into
Closed
apps: git-back scaffolded apps when init runs inside a Git repo#6406atreyadbrx wants to merge 2 commits into
atreyadbrx wants to merge 2 commits into
Conversation
`databricks apps init` now detects the Git repository that will contain the new app and scaffolds a git-backed databricks.yml — git_repository (origin url + inferred provider) and git_source (current branch + repo-relative source_code_path) — instead of a plain source_code_path upload. Detection is best-effort and conservative: it falls back to source_code_path when there is no repo, no origin remote, an unrecognized provider host, a detached HEAD, or a destination outside the repo, so it never emits an unusable git block. Backward compatible with the AppKit template: older CLIs render the git fields empty and the template keeps source_code_path. Pairs with the AppKit template change in databricks/appkit#556. Co-authored-by: Isaac <no-reply@databricks.com> Signed-off-by: atreyadbrx <atreya.misra@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com> Signed-off-by: atreyadbrx <atreya.misra@databricks.com>
atreyadbrx
added a commit
to atreyadbrx/appkit
that referenced
this pull request
Aug 27, 2026
Replace the commented git_repository/git_source example with a conditional that the Databricks CLI's `apps init` fills in when scaffolding inside a Git repository (databricks/cli#6406). When the CLI detects an origin remote it renders a real git_repository (url + provider) and git_source (branch + repo-relative source_code_path); otherwise the template keeps source_code_path, so older CLIs and non-repo scaffolds are unaffected. Co-authored-by: Isaac <no-reply@databricks.com> Signed-off-by: atreyadbrx <atreya.misra@databricks.com>
Contributor
Approval status: pending
|
Collaborator
Integration test reportCommit: c9afa34
Top 3 slowest tests (at least 2 minutes):
|
Collaborator
Author
|
Closing — changing direction per review feedback. Instead of detecting git at apps init/create time, git-backing will be an explicit opt-in migration for existing apps, driven by the databricks-apps skill (using the already-shipped apps update --git-* flags for the imperative path). The detection and gh-repo-create logic here will be salvaged into that migration skill. |
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
databricks apps initnow detects the Git repository that will contain the new app and scaffolds a git-backeddatabricks.yml— agit_repository(origin URL + inferred provider) andgit_source(current branch + repo-relativesource_code_path) — instead of a plainsource_code_pathupload.cmd/apps/gitsource.go:detectGitScaffoldSourcewalks up from the scaffold destination viagit.FetchRepositoryInfo, normalizes the origin remote to an https URL, and maps the host to a Databricks git provider (gitHub,gitLab,bitbucketCloud,azureDevOpsServices).cmd/apps/init.go: the detected fields are threaded into the template context (agitmap), so the AppKitdatabricks.yml.tmplcan render the block conditionally.Detection is conservative and falls back to
source_code_pathwhen there is nothing safe to point a deploy at: no repo, no origin remote, an unrecognized/self-hosted provider host, a detached HEAD, or a destination outside the repo. It therefore never emits an unusable git block.Why
Git-backed deployment (deploy from a repo/ref rather than uploading local files) is the recommended path for Databricks Apps — it is reproducible, reviewable, and rollback-able. Today a scaffolded app defaults to a local
source_code_pathand the git block is a commented placeholder the user must fill in by hand, so almost nobody adopts it. Auto-detecting the repo the user is already standing in makes git-backed the default with zero extra steps, while degrading cleanly to the old behavior everywhere else.Pairs with the AppKit template change in databricks/appkit#556 (the template renders the
git_repository/git_sourceblock from these fields). Backward compatible: an older CLI renders the git fields empty and the template keepssource_code_path.Tests
cmd/apps/gitsource_test.gocover provider inference, origin-URL normalization (https,.gitsuffix, scp-style ssh, credential stripping, unknown hosts), anddetectGitScaffoldSourceacross repo-root/in-place, subdirectory, not-yet-created subdir, no-repo, no-origin, unknown-provider, and detached-HEAD cases.This pull request and its description were written by Isaac.