Skip to content

bundle: add bundle.managed_state config field + DMS test server#5333

Draft
shreyas-goenka wants to merge 2 commits into
shreyas-goenka/bundle-lock-abstractionfrom
shreyas-goenka/bundle-managed-state-gate
Draft

bundle: add bundle.managed_state config field + DMS test server#5333
shreyas-goenka wants to merge 2 commits into
shreyas-goenka/bundle-lock-abstractionfrom
shreyas-goenka/bundle-managed-state-gate

Conversation

@shreyas-goenka
Copy link
Copy Markdown
Contributor

Changes

Introduce the managed-state configuration gate that future commits (starting with #5331) will use to swap deployment locking, and later resource state management, between the historical workspace-filesystem implementation and the new Deployment Metadata Service (DMS) implementation.

The gate mirrors the existing bundle.engine pattern:

  • bundle/config/managedstate/managedstate.go exposes the DATABRICKS_BUNDLE_MANAGED_STATE env var, a Default constant, and a Setting struct with location-aware source attribution. FromEnv is tolerant of boolean spelling (yes/no/y/n in addition to strconv.ParseBool spellings).
  • config.Bundle.ManagedState (json:"managed_state") is the bundle config knob.
  • cmd/bundle/utils.ResolveManagedStateSetting layers config > env > Default with file/line source attribution.

Also lands the in-memory bundle deployment metadata service test fixture (libs/testserver/deployment_metadata.go and route registrations) so the follow-up that wires the real DMS-backed lock can add its acceptance tests without further test-infra churn.

Tests

  • bundle/config/managedstate: unit coverage for env-var parsing, including boolean-spelling tolerance and invalid-value error.
  • cmd/bundle/utils: ResolveManagedStateSetting priority tests mirroring ResolveEngineSetting.
  • acceptance/bundle/managed-state/gate-config: asserts the config field surfaces through bundle validate -o json.
  • acceptance/bundle/managed-state/gate-env: documents that the env var deliberately does not mutate validated config; it is consumed lazily at deploy/destroy/bind/unbind time.

Behavior

No behavior changes for existing bundles -- nothing yet consumes the new setting. The DMS-backed lock implementation that does consume it lands in #5331, which is rebased on top of this branch.

Stack

Pure code-movement refactor. Wraps the existing workspace-filesystem lock
behavior behind a DeploymentLock interface so a follow-up PR can introduce
an alternative metadata-service-backed lock implementation without
touching deploy/destroy/bind callers again.

What changed:
- New bundle/deploy/lock/lock.go: DeploymentLock interface, Goal enum
  (moved from release.go), DeploymentStatus enum, and a
  NewDeploymentLock factory that unconditionally returns the workspace
  filesystem implementation.
- New bundle/deploy/lock/workspace_filesystem.go: workspaceFilesystemLock
  struct that implements DeploymentLock. Preserves the historical
  behavior of the deleted acquire.go / release.go mutators: lock-disabled
  short-circuit, locker.CreateLocker initialization, the
  permissions.ReportPossiblePermissionDenied branch on fs.ErrPermission
  / fs.ErrNotExist, and the destroy-mode locker.AllowLockFileNotExist
  unlock quirk.
- Deleted bundle/deploy/lock/acquire.go and bundle/deploy/lock/release.go.
- Updated bundle/phases/{deploy,destroy,bind}.go to construct the lock
  once via NewDeploymentLock and call Acquire / Release directly instead
  of through bundle.ApplyContext. The deferred Release now reports
  DeploymentSuccess / DeploymentFailure based on logdiag.HasError so a
  future DMS-backed implementation can record the outcome.

Behavior is preserved end-to-end: lock-related acceptance goldens
(pipelines/{deploy,destroy}/force-lock, bundle/help/bundle-{deploy,
destroy}) all pass unchanged.
Introduce the managed-state configuration gate that future commits will
use to swap deployment locking (and, later, resource state management)
between the historical workspace-filesystem implementation and the new
Deployment Metadata Service (DMS) implementation.

The gate mirrors the existing bundle.engine pattern:

  - bundle/config/managedstate/managedstate.go exposes the
    DATABRICKS_BUNDLE_MANAGED_STATE env var, a Default constant, and a
    Setting struct with location-aware source attribution.
  - config.Bundle.ManagedState (json:"managed_state") is the bundle
    config knob.
  - cmd/bundle/utils.ResolveManagedStateSetting layers config > env >
    Default with file/line source attribution.

Also lands the in-memory bundle deployment metadata service test
fixture (libs/testserver/deployment_metadata.go and route
registrations) so a follow-up that wires the real DMS-backed lock can
add its acceptance tests without further test-infra churn.

Acceptance coverage:
  - acceptance/bundle/managed-state/gate-config asserts the config
    field surfaces through bundle validate -o json.
  - acceptance/bundle/managed-state/gate-env documents that the env
    var deliberately does not mutate validated config (it is consumed
    lazily at deploy/destroy/bind/unbind time).

No behavior changes for existing bundles -- nothing yet consumes the
new setting.
@shreyas-goenka shreyas-goenka force-pushed the shreyas-goenka/bundle-managed-state-gate branch from c52df0c to dccd2d0 Compare May 26, 2026 19:28
@eng-dev-ecosystem-bot
Copy link
Copy Markdown
Collaborator

Commit: dccd2d0

Run: 26470352318

@shreyas-goenka shreyas-goenka force-pushed the shreyas-goenka/bundle-lock-abstraction branch from ff910cd to ee860e8 Compare June 1, 2026 15:31
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