apps: interactive Git onboarding for init outside a repo - #6411
apps: interactive Git onboarding for init outside a repo#6411atreyadbrx wants to merge 2 commits into
Conversation
When `databricks apps init` runs outside any Git repository, it now offers to set up git-backed deployment interactively (recommended by default): - Create a new GitHub repository — with an authenticated `gh` CLI, the repo is created and the scaffolded app is pushed to it; the databricks.yml is rendered git-backed at the predicted URL. Without a usable `gh`, it falls back to writing the git-backed config from a URL the user supplies. - Use an existing repository — clones it into the current directory (which must be empty) and scaffolds the app in place; the cloned origin is picked up by the existing detection pass. Repo creation is deferred until after the project is fully initialized so a successful create/push is never orphaned by a later failure, and the clone path refuses to overwrite a non-empty repository. Non-interactive/flags mode is unaffected and continues to rely on passive detection. Co-authored-by: Isaac <no-reply@databricks.com> Signed-off-by: atreyadbrx <atreya.misra@databricks.com>
Approval status: pending
|
Integration test reportCommit: 15574c7
Top 3 slowest tests (at least 2 minutes):
|
The interactive "create a new GitHub repository" path always created the repo under the authenticated user's personal account. Add an owner picker (personal account plus the orgs the user belongs to, from `gh api user/orgs`) so an app repo can be created in a company org. The predicted URL and git_repository.url derive from the selected owner. Falls back to the personal account when the user has no orgs or the token can't list them. Co-authored-by: Isaac <no-reply@databricks.com> Signed-off-by: atreyadbrx <atreya.misra@databricks.com>
|
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. |
2 participants
Changes
When
databricks apps initruns outside any Git repository (interactive mode only), it now offers to set up git-backed deployment — recommended, default yes:ghCLI, the repo is created and the scaffolded app pushed to it;databricks.ymlis rendered git-backed at the predictedhttps://github.com/<owner>/<name>. Without a usablegh, it falls back to writing the git-backed config from a URL the user supplies (repo creation left to them).New:
cmd/apps/gitonboard.go(orchestration +gh/githelpers),libs/apps/prompt/git.go(the huh prompts),isInGitRepogate ingitsource.go, and wiring ininit.go.Why
#6406 makes a scaffold git-backed when you're already in a repo. This closes the other half: the common case where the user has no repo yet. Rather than silently defaulting to a local
source_code_pathupload,apps initwalks them into a repo (create or clone) so git-backed deployment — the recommended path for Databricks Apps — is the default outcome, not something they have to discover and wire up by hand.Safety:
ghfailure is non-fatal — the git-backeddatabricks.ymlis still written with guidance to create/push manually.--name(flags) mode is unaffected and relies on passive detection only.Tests
dirIsEmpty,dirHasOnlyGitbehavior viadefaultRepoName/empty-dir checks); provider inference and URL normalization are covered in apps: git-back scaffolded apps when init runs inside a Git repo #6406.cmd/appsandlibs/apps/prompttest packages pass. The interactive prompts andgh/git cloneexec paths are exercised manually (they shell out to external tools).This pull request and its description were written by Isaac.