Repository navigation
Conversation
`bundle deploy --plan plan.json --force` reused the zip staged when the plan was produced. If the snapshot was untouched at plan time and the content had not changed, that zip carries the previous snapshot's name and the plan holds a skip, so the forced deploy stayed on the snapshot that was modified in the workspace, contrary to what --force promises. Detect this case and ask the user to rerun `bundle plan --force`, which moves the deployment to a fresh snapshot. Co-authored-by: Isaac <no-reply@databricks.com>
pietern
force-pushed
the
pietern/f05-6774-snapshot-force-plan
branch
from
November 4, 2026 10:09
7fb73fa to
aa3e234
Compare
Contributor
|
Commit: Regression test reportSelected 1 changed tests (limit=20, 0 not selected) 1 tests: regression=1 unreleased=0 coverage=0 failing=0
TestAccept/bundle/deploy/immutable/breakglass/DMS=: branch ✅ | main (e1b8c92) ❌ | latest (v1.24.0) ❌main (e1b8c92): latest (v1.24.0): same output as main (e1b8c92) |
Collaborator
Integration test reportCommit: 7b865e1
Top 3 slowest tests (at least 2 minutes):
|
The error is reached when the plan was saved with a plain 'bundle plan', so "run 'bundle plan --force' again" was misleading. Co-authored-by: Isaac <no-reply@databricks.com>
| snap.ZipPath = filepath.ToSlash(zipPath) | ||
| // A plan produced while the snapshot was untouched may keep it in place. Applying it would | ||
| // leave the deployment on the modified snapshot, which --force promises to move off. | ||
| if !m.clean && modified && snap.RelativePath() == prev.RelativePath { |
Contributor
There was a problem hiding this comment.
With this plan, deploy --plan plan.json without --force still fails at line 297 with "To confirm it, use the --force flag", and adding the flag lands here with a second, different error; the plan keeps the snapshot either way, so --force was never going to help. Can the kept-snapshot check run regardless of --force (plan keeps a dirty snapshot → "create a new plan with 'bundle plan --force'"), so the first error already says what to do? The test only runs the no-change plan with --force, so the chain isn't visible in output.txt.
| @@ -0,0 +1 @@ | |||
| * `bundle deploy --plan --force` now fails instead of staying on a snapshot that was modified in the workspace after the plan was created; create a new plan with `bundle plan --force`. ([#7336](https://github.com/databricks/cli/pull/7336)) | |||
Contributor
There was a problem hiding this comment.
"snapshot" here could be read as a sync snapshot or a Postgres snapshot. The #6774 entry opens with "Immutable-folder deploys now refuse..."; can this one name immutable folders the same way?
rugpanov
removed their request for review
November 11, 2026 20:01
This branch has not been deployed
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
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.
Changes
bundle deploy --plan plan.json --forcecould stay on a snapshot that was modified in the workspace, if the plan was saved while the snapshot was clean. Applying such a plan now fails with "the last deployment was modified in the workspace since the plan was created; create a new plan with 'bundle plan --force' to move to a new snapshot".Why
#6774 makes
--forcemove the deployment to a fresh snapshot; that didn't hold fordeploy --plan.Tests
Extended
acceptance/bundle/deploy/immutable/breakglass.This pull request and its description were written by Isaac.