Fix bundle.deployment.lock.force being ignored

[janniklasrose]

Changes

bundle.deployment.lock.force had no effect. Setting it in databricks.yml did not let a deploy break through a stale deployment lock — only the --force-lock flag worked.

The flag was assigned unconditionally inside InitFunc, which runs after the bundle configuration is loaded (cmd/bundle/utils/process.go:138). With the flag absent, its zero value false overwrote a force: true from config:

b.Config.Bundle.Force = force
b.Config.Bundle.Deployment.Lock.Force = forceLock   // always overwrites config

Both halves of the lock override are then lost: libs/locker/locker.go only adds filer.OverwriteIfExists when forced, and assertLockHeld checks the IsForced field. Neither gets set, so the write fails against the existing lock exactly as if nothing had been passed.

The neighbouring flags in the very same closure were already guarded (--cluster-id, --fail-on-active-runs); --force-lock was the one that wasn't. In cmd/apps/deploy_bundle.go the enclosing function's own doc comment already stated the intended contract — "Flags that override bundle YAML are only applied when explicitly set by the user" — which forceLock did not honor.

This is a user-visible silent-ignore: the field is documented in annotations.yml, appears in the public reference docs, and passes schema validation, so users get no warning that it does nothing.

Fix: route all six sites through a new utils.SetForceLock, which applies the flag only when explicitly passed. It uses Flags().Lookup rather than cmd.Flag(...).Changed because BindResource is also reached from bundle generate, which never registers the flag and would panic on a nil return.

cmd/apps/import.go is intentionally unchanged: it forces false on a synthetic command with no flags.

Scope note on bundle.force

b.Config.Bundle.Force is clobbered the same way but is not a bug, so it is deliberately left alone. It is tagged bundle:"readonly" and libs/jsonschema/from_type.go strips readonly fields from the generated schema. Confirmed against the generated schema:

Bundle: ['cluster_id', 'compute_id', 'databricks_cli_version', 'deployment', 'engine', 'git', 'name', 'uuid']
Lock:   ['enabled', 'force']

bundle.force is not a settable field, so a flag default cannot overwrite anything a user could have set. The public reference docs likewise document deployment.lock.force but have no entry for bundle.force. Every other b.Config.* assignment in the flag paths (cluster_id, fail_on_active_runs) is already .Changed-guarded; AutoApprove, Select, and SkipLocalFileValidation live on the Bundle struct rather than Config and are not YAML-settable. lock.force was the only field affected.

Out of scope but worth noting: readonly only strips a field from the schema, so bundle.force: true in YAML is still accepted by the loader and shows up in bundle validate -o json with no warning. That gap affects every readonly field and predates this change.

Tests

New acceptance test acceptance/bundle/deploy/force-lock-config/ seeds a real stale lock held by another user, then deploys with only force: true in databricks.yml — following the existing acceptance/pipelines/deploy/force-lock/ pattern rather than asserting on request shape.

Verified it fails before the fix and passes after. Against the unfixed code it reproduces the reported error:

Error: Failed to acquire deployment lock: deploy lock acquired by user-with-lock@databricks.com at [TIMESTAMP] +0000 UTC.
Another deployment may be in progress. Use --force-lock to override, but this may
conflict with the other deployment if it is still active

With the fix the lock is overridden and the deploy completes.

cmd/apps/deploy_bundle_test.go had an assertion pinning the old behavior ("force, forceLock, autoApprove always apply"), now split into unset-flag and explicit-flag cases. The unset case pre-seeds lock.force = true via a new configure hook, since a zero-value bundle cannot detect a clobber. Also added a table-driven unit test for the helper in cmd/bundle/utils/utils_test.go.

./cmd/... 2379 passed; bundle deploy/destroy, deployment, help, pipelines and apps acceptance suites 450 passed; ./task fmt, ./task lint-q, ./task checks clean.

This pull request and its description were written by Isaac, an AI coding agent.

[eng-dev-ecosystem-bot]

Integration test report

Commit: 0e99688

Run: 31099632327

	Env	💚​RECOVERED	🙈​SKIP	✅​pass	🙈​skip	Time
💚​	aws linux	4	4	291	1111	5:14
💚​	aws windows	4	4	293	1109	4:39
💚​	azure linux	4	4	290	1111	5:59
💚​	azure windows	4	4	292	1109	5:50
💚​	gcp linux	1	5	291	1111	5:33
💚​	gcp windows	1	5	293	1109	5:53

8 interesting tests: 4 RECOVERED, 4 SKIP

	Test Name	aws linux	aws windows	azure linux	azure windows	gcp linux	gcp windows
💚​	TestAccept	💚​R	💚​R	💚​R	💚​R	💚​R	💚​R
🙈​	TestAccept/bundle/invariant/no_drift	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
🙈​	TestAccept/bundle/resources/vector_search_endpoints/drift/recreated_same_name	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
🙈​	TestAccept/bundle/resources/vector_search_indexes/recreate/embedding_dimension	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
🙈​	TestAccept/ssh/connection	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S	🙈​S
💚​	TestFetchRepositoryInfoAPI_FromRepo	💚​R	💚​R	💚​R	💚​R	🙈​S	🙈​S
💚​	TestFetchRepositoryInfoAPI_FromRepo/root	💚​R	💚​R	💚​R	💚​R
💚​	TestFetchRepositoryInfoAPI_FromRepo/subdir	💚​R	💚​R	💚​R	💚​R

Top 3 slowest tests (at least 2 minutes):

duration	env	testname
5:11	gcp windows	TestAccept
3:50	azure windows	TestAccept
3:18	aws windows	TestAccept