New hidden install-pipelines-cli command that creates pipelines symlink to databricks#3009
Conversation
…atabricks CLI with tests
acceptance/acceptance_test.go
Outdated
| // Make helper scripts available | ||
| t.Setenv("PATH", fmt.Sprintf("%s%c%s", filepath.Join(cwd, "bin"), os.PathListSeparator, os.Getenv("PATH"))) | ||
| pathDirs := []string{filepath.Join(cwd, "bin"), buildDir} | ||
| t.Setenv("PATH", fmt.Sprintf("%s%c%s", strings.Join(pathDirs, string(os.PathListSeparator)), os.PathListSeparator, os.Getenv("PATH"))) |
There was a problem hiding this comment.
This adds buildDir to PATH? What for?
There was a problem hiding this comment.
If the goal is to expose dlt command to test then we should
- modify BuildCLI to link databricks to dlt
- export $DLT env var pointing to built dlt (+ replacement)
There was a problem hiding this comment.
The intention here was probably so dlt can be found on the build path when it's built, but we should probably export the $DLT env var the same way we do it for CLI and other envs.
qq: maybe I misunderstood, wdym by "+ replacement" here?
@denik / @kanterov high level question here: we should be definitely adding acceptance tests, but in general does it hurt to have unit tests as well? A quick look through the repo and it feels like some files have more unit tests while others don't. For this command specifically, I think it's helpful to test the edge cases for which PATH might not contain databricks, target local isn't writable etc... WDYT? |
Depends on code being test; if it's a pure function / class, makes sense to cover edge cases with unit tests. If it involves reading env vars, command line arguments then acceptance tests typically provide more realistic setup. |
8711e41 to
ca3d09b
Compare
d1f1df0 to
d168e96
Compare
085a428 to
9d53ff8
Compare
ac4799e to
45c7df1
Compare
45c7df1 to
12b1e64
Compare
acceptance/dlt/install-dlt/script
Outdated
|
|
||
| title "Executable not called as databricks" | ||
| cp $CLI notdatabricks | ||
| dlt=$(trace errcode ./notdatabricks install-dlt -o json | jq -r .symlink_path) |
There was a problem hiding this comment.
It's also not clear here what's being asserted.
There was a problem hiding this comment.
In the case that the user has databricks aliased, want to make sure the install-dlt command still works.
554264e to
515956f
Compare
515956f to
1da3ff0
Compare
main.go
Outdated
| // binary to be used for both DLT and databricks CLI commands. | ||
| func getCommand(ctx context.Context) *cobra.Command { | ||
| invokedAs := filepath.Base(os.Args[0]) | ||
| if invokedAs == "dlt" || (runtime.GOOS == "windows" && invokedAs == "dlt.exe") { |
There was a problem hiding this comment.
nit: you can replace it with strings.StartsWith for invokedAs as nit
andrewnester
left a comment
There was a problem hiding this comment.
Approved to unblock but first symlink needs to be renamed from dlt to pipelines
pietern
left a comment
There was a problem hiding this comment.
Please update the PR title and summary to reflect the new state of the PR.
dlt symlink to databrickspipelines symlink to databricks
pipelines symlink to databricksinstall-pipelines-cli command that creates pipelines symlink to databricks
0fd2c95 to
9156ad5
Compare
|
An authorized user can trigger integration tests manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
## Changes This PR removes the unused standalone pipelines CLI entrypoint infrastructure. The ability to invoke the CLI binary as `pipelines` (instead of `databricks`) was never released and is no longer needed. All pipelines functionality remains available through `databricks pipelines` commands. PRs that added this: - #3009 - #3114 - #3170 - #3177 - #3221 ## Tests Updated acceptance tests. --------- Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Changes
pipelines.go(packagepipelines)install_pipelines_cli.go(packagepipelines)databricks, implements a hiddeninstall-pipelines-clicommand that creates a symlink namedpipelinespointing to the realdatabricksbinary.pipelines/install-pipelines-cliacceptance testmain.goreturns a root depending on if the binary is invoked aspipelines/pipelines.exeordatabricksWhy
pipelinesas a standalone CLI, which internally points to the maindatabricksbinary. This is a step towards a dedicated Pipelines CLI experience, while minimizing code duplication.Tests
install-pipelines-cliin pipelines to check if success messagepipelines successfully installedis printedCreates temporary directory and verifies successful symlink creation.
Validates CLI output and stub command functionality.
Confirms graceful handling when symlink already exists.
Ensures installation fails when regular file exists at target path.
Verifies installation works when databricks binary is renamed/called via alias.