[BUG] Bundles Force Acquire Lock is broken

[stikkireddy]

Describe the bug
bf deploy --force-acquire-lock isnt mapping to the right bundles arg.

Fix

brickflow/brickflow/cli/bundles.py

Lines 89 to 93 in 273fe7e

	"""CLI deploy the bundle."""
	deploy_args = ["deploy", "-e", get_bundles_project_env()]
	if force_acquire_lock is True:
	deploy_args.append("--force-lock")
	exec_command(get_valid_bundle_cli(bundle_cli), "bundle", deploy_args)

To Reproduce

Bundle is called --force-deploy and force not --force-lock

Deploy bundle

Usage:
  databricks bundle deploy [flags]

Flags:
  -c, --compute-id string   Override compute in the deployment with the given compute ID.
      --force               Force-override Git branch validation.
      --force-deploy        Force acquisition of deployment lock.
  -h, --help                help for deploy

Global Flags:
  -e, --environment string       bundle environment to use (if applicable)
      --log-file file            file to write logs to (default stderr)
      --log-format type          log output format (text or json) (default text)
      --log-level format         log level (default disabled)
  -o, --output type              output type: text or json (default text)
  -p, --profile string           ~/.databrickscfg profile
      --progress-format format   format for progress logs (append, inplace, json) (default default)
      --var strings              set values for variables defined in bundle config. Example: --var="foo=bar"

[nachatz]

I can pick this up if still available. How should this be handled considering recent Databricks CLI versions resolve this naming convention? Shall we include a version check to dynamically determine the argument?

i.e. if version is below 0.203.x use force-deploy, if greater use force-lock?

[stikkireddy]

@asingamaneni should we support older versions of CLI as we pin a brickflow version to a specific version of the CLI?

[newfront]

It's probably worth supporting N versions back and handling the internal mapping for the bundle locking.

@nachatz the idea of splitting the command based on the local version of the cli is a good idea.

[asingamaneni]

@asingamaneni should we support older versions of CLI as we pin a brickflow version to a specific version of the CLI?

I think a range would be better as we are not exactly pinning the version right -

brickflow/pyproject.toml

Line 46 in 5a10093

databricks-sdk = ">=0.1.8 <1.0.0"

?

[stikkireddy]

@asingamaneni referring to the databricks golang cli not the sdk.

[asingamaneni]

@nachatz would you like to pick this up? We will want to support older versions for the next release and deprecate it later in the future versions.

[nachatz]

@nachatz would you like to pick this up? We will want to support older versions for the next release and deprecate it later in the future versions.

@asingamaneni Looks like this was already picked up: #51 . Happy to contribute if I misinterpreted

[asingamaneni]

Yes, this is handled in the pr. Thanks for the help!