bundle: extract DeploymentLock interface + workspace filesystem impl#5314
Draft
shreyas-goenka wants to merge 1 commit into
Draft
bundle: extract DeploymentLock interface + workspace filesystem impl#5314shreyas-goenka wants to merge 1 commit into
shreyas-goenka wants to merge 1 commit into
Conversation
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.
shreyas-goenka
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
shreyas-goenka
temporarily deployed
to
test-trigger-is
GitHub Actions
Inactive
Collaborator
|
Commit: 09f9090 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Pure code-movement refactor. Wraps the existing workspace-filesystem lock behind a
DeploymentLockinterface so a follow-up PR can ship a metadata-service-backed implementation without touchingdeploy/destroy/bindcallers again. The interface and filesystem behavior split mirrors what landed in the kitchen-sink PR #4856 (shreyas-goenka/deployment-metadata-service) but ships only the refactor here. No env var, no DMS code, notmpdmsorstatemgmt.IsDmsActivereferences.What changed
bundle/deploy/lock/lock.go—DeploymentLockinterface,Goalenum (moved fromrelease.go),DeploymentStatusenum, and aNewDeploymentLockfactory that unconditionally returns the workspace filesystem implementation.bundle/deploy/lock/workspace_filesystem.go—workspaceFilesystemLockimplementsDeploymentLock. Preserves the historical behavior of the deleted mutators: lock-disabled short-circuit,locker.CreateLockerinitialization, thepermissions.ReportPossiblePermissionDeniedbranch onfs.ErrPermission/fs.ErrNotExist, and the destroy-modelocker.AllowLockFileNotExistunlock quirk.bundle/deploy/lock/acquire.goandbundle/deploy/lock/release.go.bundle/phases/{deploy,destroy,bind}.goto construct the lock once viaNewDeploymentLockand callAcquire/Releasedirectly instead of viabundle.ApplyContext. The deferredReleasenow passesDeploymentSuccess/DeploymentFailurebased onlogdiag.HasError(ctx)so a future DMS-backed implementation can record the outcome.Diff shape
No new package dependencies.
Test plan
go build ./...cleango vet ./bundle/deploy/lock/... ./bundle/phases/...cleango test ./bundle/... ./cmd/...green-update:pipelines/{deploy,destroy}/force-lock,bundle/help/bundle-{deploy,deployment,deployment-migrate,destroy}./task lintclean (0 issuesx3)databricks/cliPre-existing acceptance failures on
origin/main(bundle/deployment/bind/job/...,bundle/templates/pydabs/check-consistency,bundle/resources/jobs/update*, etc.) reproduce identically on this branch and are unrelated to this refactor.