Skip to content

Support bundle deployment bind for DMS-recorded deployments - #6590

Draft
shreyas-goenka wants to merge 5 commits into
mainfrom
isaac/dms-bindunbind
Draft

Support bundle deployment bind for DMS-recorded deployments#6590
shreyas-goenka wants to merge 5 commits into
mainfrom
isaac/dms-bindunbind

Conversation

@shreyas-goenka

@shreyas-goenka shreyas-goenka commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Changes

databricks bundle deployment bind now works for deployments that record history with the deployment metadata service (DMS). Bind is a first-class plan action: the resource is planned as Bind (config already matches the existing workspace resource) or BindAndUpdate (config differs) and applied immediately — DMS is the source of truth — recording a BIND / BIND_AND_UPDATE operation.

Unbind under DMS is descoped for now: there is no unbind operation action type yet, so bundle deployment unbind continues to error for a DMS-recorded deployment rather than staging an unverified enum.

Why

The file-based bind stages a change for the next deploy; under DMS the recorded state is the source of truth, so bind plans and applies the adoption in one step (Bind = adopt unchanged, BindAndUpdate = adopt and apply config). This adds Bind/BindAndUpdate to the deployplan and the direct engine's plan/apply, and maps them to the DMS BIND / BIND_AND_UPDATE operation action types.

Tests

The existing file-based bind/unbind acceptance suites stay on the deferred path, since immediate DMS bind cannot share their goldens. New bundle/dms/bind covers a plain BIND (a schema whose config matches the existing resource) and a BIND_AND_UPDATE (a job whose config differs, plus its permissions), verifies only the bound resource's subtree is recorded while other resources are left untouched, and chains a second bind onto the first version. bundle/dms/record-op-fault asserts the version is completed with failure when the operation upload fails.

This pull request and its description were written by Isaac.

Bind and unbind now record their change with the deployment metadata
service instead of refusing when experimental.deployment_history is on,
using bind/unbind operation action types. Enables the DMS variant for the
bind/unbind acceptance tests; the few that assert job/pipeline deployment
stamps or dumped state stay opted out.

Co-authored-by: Isaac <no-reply@databricks.com>
@eng-dev-ecosystem-bot

eng-dev-ecosystem-bot commented Sep 9, 2026

Copy link
Copy Markdown
Collaborator

Integration test report

Commit: 633c9b5

Run: 34470947797

Env ❌​FAIL 🟨​KNOWN ✅​pass 🙈​skip Time
❌​ aws linux 2 1 275 16 6:50
❌​ aws windows 2 1 277 14 6:14
❌​ azure linux 2 1 274 16 6:25
❌​ azure windows 2 1 276 14 5:57
❌​ gcp linux 2 1 275 16 7:36
❌​ gcp windows 2 1 277 14 6:51
Test Name aws linux aws windows azure linux azure windows gcp linux gcp windows
🟨​ TestAccept 🟨​K 🟨​K 🟨​K 🟨​K 🟨​K 🟨​K
❌​ TestAccept/bundle/dms/bind ❌​F ❌​F ❌​F ❌​F ❌​F ❌​F
❌​ TestAccept/bundle/dms/bind/DATABRICKS_BUNDLE_ENGINE=direct/DMS=true ❌​F ❌​F ❌​F ❌​F ❌​F ❌​F

shreyas-goenka and others added 4 commits September 9, 2026 22:17
- Always complete the DMS version (with failure on error) after starting it,
  so a bind/unbind recording failure does not leak the version's lease, matching
  the deploy and destroy paths.
- FetchDeployment now returns the parsed last version id, dropping the duplicate
  parse in phases and process.go, and keeps the half-created-deployment TODO that
  was dropped when it moved to libs/dms.
- Extract openRecordedState and tighten comments.
- New bundle/dms/record-op-fault test asserts the version completes with failure
  when the operation upload fails; bundle/dms/bind-unbind now cleans up and
  asserts the resource is managed after bind and re-created after unbind.

Co-authored-by: Isaac <no-reply@databricks.com>
Bind is now a first-class plan action. `bundle deployment bind` plans the
resource as Bind (config already matches the existing workspace resource) or
BindAndUpdate (config differs) and applies it immediately, because the metadata
service is the source of truth - unlike the file-based bind, which stages the
change for the next deploy. Adds Bind/BindAndUpdate to deployplan and the direct
engine's plan/apply, maps them to the BIND / BIND_AND_UPDATE operation types,
and drops the seed-state machinery the previous approach needed.

The general bind/unbind acceptance tests stay on the file-based (deferred) path,
since immediate DMS bind cannot share their goldens; DMS bind/unbind is covered
by the dedicated bundle/dms/bind-unbind and record-op-fault tests.

Co-authored-by: Isaac <no-reply@databricks.com>
The plan-based bind no longer builds a seed state, so drop the helper it needed.

Co-authored-by: Isaac <no-reply@databricks.com>
Descope unbind under the deployment metadata service: no unbind operation
action type exists yet, so it reverts to erroring rather than staging an
unverified enum. Fix reference resolution so binding a resource that has
permissions resolves the adopted id from the plan entry instead of state.
Add end-to-end coverage for a plain bind (schema, unchanged) and a
bind-and-update (job, reconciled) plus FilterToSelected multi-resource
exclusion, and share the deployment create-and-stamp helper between the
deploy and bind phases.

Co-authored-by: Isaac <no-reply@databricks.com>
@shreyas-goenka shreyas-goenka changed the title Support bundle deployment bind/unbind for DMS-recorded deployments Support bundle deployment bind for DMS-recorded deployments Sep 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants