Tag versions

[sburns]

I know there are a lot of disclaimers about not using this production, but that hasn't stopped us, or others, if I'm guessing :)

It would be nice to tag these releases, either w/ simple git tags or more formal GitHub releases, so users could pin their curl URL to something stable like https://raw.githubusercontent.com/databricks/setup-cli/0.203.2/install.sh (note the branch is not main but a version) and install a known version of the CLI.

Love the work and progress here!

[bradleyjamrozik]

I second this request.

[pietern]

I agree this is sort of table stakes and should be added. For the GitHub Action we added a version parameter in #30. This doesn't apply to the raw installer though, and setting up proper tags would solve for both the action and the installer.

What kind of CI/CD system (or other system) are you calling the installer from?

[sburns]

I'm working with an in-house, home grown system, just writing shell scripts to build, test, and deploy. The big reason this came up last week was the switch from --environment to --target. The current version says --environment is deprecated, but in practice this causes a panic because the workspace URLs didn't match during the bundle deploy if you're using --environment to point to a different workspace URL.

[bradleyjamrozik]

I am using Azure DevOps pipelines, installing the CLI via the install.sh shell command

[andrewnester]

The current version says --environment is deprecated, but in practice this causes a panic because the workspace URLs didn't match during the bundle deploy if you're using --environment to point to a different workspace URL.

@sburns Could you please elaborate on this a bit? The panic in this case is unexpected and mostly likely means a bug on our side. If you can share example of configuration and the commands which failed it can help us to identify the issue.

Thanks!

[sburns]

Sure, I can't find the logs anymore, but how I read the error was that we were using the --environment flag to specify a specific workspace and a --profile to specify authentication. The environment wasn't honored, so it fell back to the default workspace, which differed from the workspace given in the profile and caused a panic.

[andrewnester]

@sburns thanks for the details! Indeed, it appears a bug on our side which should be fix by this PR databricks/cli#705

Sorry for the inconvenience.