template: git-backed deployment in scaffolded databricks.yml (proposal)

[atreyadbrx]

Proposal: git-backed deployment by default for scaffolded apps

This makes a newly scaffolded AppKit app deploy from its Git repository instead of uploading local files — automatically, whenever databricks apps init runs inside a Git repo with a remote. It's a proposal for discussion; happy to adjust shape/scope.

What changes here (AppKit)

template/databricks.yml.tmpl replaces the commented git_repository/git_source example with a conditional block:

{{- if .git.url}}
      git_repository:
        url: {{.git.url}}
        provider: {{.git.provider}}
      git_source:
        branch: {{.git.branch}}
        source_code_path: {{.git.sourceCodePath}}
{{- else}}
      source_code_path: ./
{{- end}}

What makes it active (paired CLI change)

The template fields are populated by a paired change in the Databricks CLI — databricks/cli#6406 — which detects the Git repo containing the app at apps init time and derives the origin URL, provider (gitHub/gitLab/bitbucketCloud/azureDevOpsServices), current branch, and repo-relative source path. Detection is conservative: it falls back to source_code_path when there's no repo, no origin, an unknown provider host, a detached HEAD, or an out-of-repo destination.

Net effect: git clone <repo> && cd <repo> && databricks apps init produces a git-backed databricks.yml with zero extra steps. Outside a repo, behavior is unchanged.

Safe / backward-compatible

• Bundle validation requires exactly one of source_code_path or git_source; the conditional emits exactly one, never both.
• Older CLIs render .git.url empty (missingkey=zero) → the else branch keeps source_code_path. So this template works with any CLI version.
• Verified: the template renders valid YAML in both branches.

Questions for the reviewer

1. Is the scaffold template the right home for this, given the detection logic necessarily lives in the CLI's apps init?
2. Are you comfortable making git-backed the default whenever scaffolding inside a repo with a remote (vs. opt-in)? A deploy still requires the code to be committed and pushed first — the rendered comment says so.
3. Any concerns with the provider-host mapping or the conservative fallbacks?

This pull request and its description were written by Isaac.

[pkosiec]

Reviewed with the paired cli#6406 👍

One more for the git-backed comment block: a private repo needs a linked git credential on the workspace for the provider. The scaffold cannot detect visibility, so a private repo without one fails at deploy. We should document it and also support during the E2E flow.

[pkosiec]

This is not safe against a CLI that does not set the git map.

The PR says older CLIs render .git.url empty and fall to the else branch. It is the opposite: with no git key, {{if .git.url}} fails hard ("nil pointer evaluating interface {}.url"). Under missingkey=zero the first lookup (.git) returns a nil interface, then the chained .url panics.

In practice the default path is safe, because cli-compat.json pins each CLI version to a template tag. But --version latest, or an explicit --version <new>, on any pre-#6406 CLI clones this template and breaks.

Have the CLI set git only when detection is active (nil otherwise), and use a single with/else here. That drops the chained field access and reads cleaner:

    {{- with .git}}
          git_repository:
            url: {{.url}}
            provider: {{.provider}}
          git_source:
            branch: {{.branch}}
            source_code_path: {{.sourceCodePath}}
    {{- else}}
          source_code_path: ./
    {{- end}}

with tests the value itself, so a missing or nil git safely takes the else. This needs the CLI to pass git only when active, since a non-empty map is always truthy. (Note: text/template and does not short circuit, so {{if and .git .git.url}} would still error.)