databricks-template/databricks.yml at main · andre-salvati/databricks-template · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
# See https://docs.databricks.com/dev-tools/bundles/index.html for documentation.
bundle:
  name: default_python
  databricks_cli_version: ">=1.9.0"
  engine: direct

artifacts:
  default:
    type: whl
    build: uv build --wheel
    path: .

include:
  - resources/*.yml

# Here is a good reference on how to structure your catalogs, workspaces, and groups:
# https://youtu.be/CLBq4fBE2Ro
#
# For staging and prod, target-level `run_as` and `workspace.root_path` are injected
# by scripts/sdk_generate_template_job.py into resources/jobs.yml (merged in via
# `include: resources/*.yml`). Keeping them in the generated file lets the SP UUID
# live in a single place — resolved by display name at generation time — so this
# file stays portable across forks that wire up a different SP.
targets:
  dev:
    mode: development
    default: true
    workspace:
      profile: dev

  staging:
    workspace:
      profile: staging

  prod:
    # mode: production + the target-level run_as injected by the generator is what
    # actually enforces the deployer-identity check. Without a target-level run_as,
    # mode: production has nothing to compare the deployer against and silently
    # falls through. The SP-pinned root_path (also injected) makes the workspace
    # ACL block non-SP deployers too — two independent gates.
    mode: production
    workspace:
      profile: prod