integration: add e2e tests for environments setup-local

[rugpanov]

Changes

Adds integration/cmd/environments/setup_local_test.go — end-to-end integration tests for databricks environments setup-local that run in the cli-isolated e2e workflow (isolated AWS/Azure/GCP workspaces). Three CLOUD_ENV-gated tests, all against the real public databricks/environments repo:

• serverless full provision — --serverless-version 5 --output json: resolve → fetch → uv sync → validate, asserting a real .venv/uv.lock and the JSON contract (ok, compute.source/envKey, resolved.pythonVersion/dbconnectVersion/artifactSource, all phases ok).
• --dry-run writes nothing — asserts the temp project dir stays empty.
• unpublished version — --serverless-version 9999 → E_ENV_UNSUPPORTED at the fetch phase with a non-zero exit.

Why

The pipeline was covered hermetically (unit + acceptance via --dry-run/stubs) and by one env-gated real-provision test in libs/localenv, but nothing drove the command end to end through the CLI entrypoint in the integration suite. Serverless needs no running compute (the version is used verbatim), so these give real e2e coverage without a cluster dependency. They skip cleanly when CLOUD_ENV is unset, so unit-test CI is unaffected.

Tests

• All three pass against a real dev workspace + the public repo (full provision ~6.6s; dry-run and error-path fast).
• go vet + golangci-lint clean; skip verified with CLOUD_ENV unset.

This PR was written by Claude Code.

[eng-dev-ecosystem-bot]

Integration test report

Commit: c4d0836

Run: 31371571279

	Env	🔄​flaky	💚​RECOVERED	🙈​SKIP	✅​pass	🙈​skip	Time
💚​	aws linux		4	4	294	1116	4:54
💚​	aws windows		4	4	296	1114	4:59
💚​	azure linux		4	4	293	1116	4:18
🔄​	azure windows	2	4	4	293	1114	3:56
💚​	gcp linux		1	5	294	1116	4:28
💚​	gcp windows		1	5	296	1114	4:25

10 interesting tests: 4 RECOVERED, 4 SKIP, 2 flaky

	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
🔄​	TestFsCpFileToDirWithOverwriteFlag	✅​p	✅​p	✅​p	🔄​f	✅​p	✅​p
🔄​	TestFsCpFileToDirWithOverwriteFlag/uc-volumes_to_uc-volumes	✅​p	✅​p	✅​p	🔄​f	✅​p	✅​p
💚​	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
3:29	azure windows	TestAccept
3:26	aws windows	TestAccept
3:19	gcp windows	TestAccept

[rclarey]

LGTM, but I didn't run it

[anton-107]

Nice addition — this fills a real gap: nothing previously drove setup-local through the CLI entrypoint with a real uv sync, and the serverless-only choice correctly avoids a cluster dependency. The assertions are also deliberately loose where the upstream artifact is mutable, which is the right instinct.

Four things I'd fix before merge (inline). The first is the one I care about most — the test installs uv on a developer's machine as a side effect, which the sibling libs/localenv/provision_integration_test.go went to deliberate lengths to avoid.

Nothing here is a correctness bug in the code under test.

On the two dry-run tests overlapping acceptance/localenv/serverless-check and env-unsupported: I'd keep them. The real-network fetch is genuine added value — the unpublished-version test verifies raw.githubusercontent.com actually 404s (rather than serving a 200 HTML page) for a missing key, which the stub server can't check.

[anton-107]

This installs uv on a developer's machine as a side effect, and the comment has it backwards: the test sets the opt-in itself, so nobody opted in.

On a machine without uv, EnvAutoInstallUv=1 makes EnsureAvailable run curl -LsSf https://astral.sh/uv/install.sh | sh, mutating ~/.local/bin (libs/localenv/uv.go:363). The sibling test avoids exactly this — requireRealProvision gates on an explicit env var and skips when uv isn't discoverable (provision_integration_test.go:27-34).

Since CI already installs uv (.github/actions/setup-build-environment/action.yml:73), the robustness this buys applies only to the case where the side effect is unwanted. Suggest dropping the Setenv and skipping instead:

if _, err := exec.LookPath("uv"); err != nil {
    t.Skipf("uv not found on PATH (%v)", err)
}

[rugpanov]

Done in 9d9c0ac — replaced with an exec.LookPath("uv") skip. You're right that the comment had it backwards: the test set the opt-in itself, so the "opted in" claim was wrong, and on a machine without uv this ran the remote installer and mutated ~/.local/bin.

[anton-107]

This assertion is tautological and can never fail. ArtifactSource is set from artifactSource(c.FromCache) (libs/localenv/pipeline.go:191), whose entire range is those two values (pipeline.go:27-30), and it's assigned in exactly one place.

The reasoning in the comment is sound (avoid flaking on a warm shared cache) — the problem is the resulting assertion reads like coverage but checks nothing.

Either isolate the cache so "network" is deterministic, or drop the line. Note there's currently no cache-dir override knob — cmd/environments/sync.go:136 uses os.UserCacheDir() unconditionally — so isolating means adding one or leaning on HOME/XDG_CACHE_HOME, neither portable. Deleting is probably the honest option.

[rugpanov]

Done in 9d9c0ac — deleted. artifactSource() only ever returns artifactCache or artifactNetwork (pipeline.go:535-540) from a single assignment site, so the membership assertion could never fail. Agreed that deleting beats adding a cache-dir override just to make it meaningful.

[anton-107]

This hardcodes the Unix layout, defeating the venvPython helper defined 5 lines below (and used in test 1). On Windows this checks a path that could never exist, so the assertion is vacuous there.

Since this is a --dry-run — preflight's ensureWritable is skipped and cache writes are suppressed (pipeline.go:141-147) — the directory should be completely empty. The stronger and simpler assertion is the same os.ReadDir + assert.Empty that TestSetupLocalDryRunWritesNothing already uses.

[rugpanov]

Done in 9d9c0ac — replaced with the os.ReadDir + assert.Empty check, matching TestSetupLocalDryRunWritesNothing. It was bypassing venvPython and vacuous on Windows; since --dry-run skips ensureWritable and suppresses cache writes, asserting the dir is empty is strictly stronger.

[anton-107]

Not this file, but related: OWNERS routes this file to team:platform rather than team:ide.

/integration/ → team:platform (.github/OWNERS:65) and findOwners is last-match-wins (.github/scripts/owners.js:97-106), so this file — squarely localenv territory — won't route to the team that owns /libs/localenv/, /cmd/environments/, and /acceptance/localenv/ (added in #6187).

Worth adding, and it must go below line 65 to win:

/integration/cmd/environments/  team:ide

[rugpanov]

Done in 9d9c0ac — added /integration/cmd/environments/ team:ide below the /integration/ rule so it wins under last-match-wins. Verified with findOwners: this file now resolves to rugpanov rclarey anton-107 misha-db, while integration/cmd/jobs/ still resolves to team:platform.

[rugpanov]

@anton-107 all four points addressed in 9d9c0ac — thanks for the review, especially the uv one.

Point	Change
uv auto-install side effect	Replaced t.Setenv(EnvAutoInstallUv, "1") with an exec.LookPath("uv") + t.Skipf, matching requireRealProvision. Comment rewritten — you were right that it claimed the developer had opted in when the test set the flag itself.
Tautological ArtifactSource assert	Deleted. artifactSource() only ever returns artifactCache or artifactNetwork from a single assignment site, so it could never fail. Agreed that deleting beats adding a cache-dir override just to make it meaningful.
Hardcoded .venv/bin/python	Replaced with os.ReadDir + assert.Empty, matching TestSetupLocalDryRunWritesNothing. Strictly stronger, and no longer vacuous on Windows.
OWNERS routing	Added /integration/cmd/environments/ team:ide below the /integration/ rule so it wins under last-match-wins.

Verified on real runners rather than just locally — all three tests pass in all six integration environments (aws/azure/gcp × linux/windows), with TestSetupLocalServerlessProvision taking 20–49s, which confirms the LookPath guard isn't silently skipping and that the new dry-run assertion holds on Windows.

One note on the OWNERS line: it won't affect this PR's own approval routing, since maintainer-approval.yml checks out pull_request.base.sha and so reads OWNERS from main. It takes effect for subsequent PRs touching this path.

The red checks are unrelated — every failing job is TestAccept/bundle/resources/model_serving_endpoints/drift/recreated_same_name, which fails on main itself (run 31175626325 on 5e3ea1c). Nothing in this PR touches the acceptance suite.

[anton-107]

Approving. Reviewed against pr/6155 head (c4d0836) with the branch checked out.

All four items from my earlier review are addressed properly, and I re-verified the two substantive ones rather than taking the summary on trust:

• The exec.LookPath("uv") + t.Skipf guard (setup_local_test.go:40) matches requireRealProvision in libs/localenv/provision_integration_test.go:32, and EnvAutoInstallUv is gone — the remote-installer side effect on a developer machine is genuinely fixed.
• The dry-run os.ReadDir + assert.Empty assertion is strictly stronger than the old hardcoded .venv/bin/python check and is no longer vacuous on Windows.
• node .github/scripts/owners.js validate passes with the new rule, and last-match-wins does put /integration/cmd/environments/ team:ide ahead of /integration/ team:platform. Your note about it only taking effect for subsequent PRs (since maintainer-approval.yml reads OWNERS from base.sha) is correct.

Two non-blocking notes — take or leave either, neither needs to hold the merge.

1. venvPython duplicates an existing helper

libs/localenv/uv.go:114 already has an identical venvPython(projectDir string) with the same Windows/Unix split. The integration test is in a different package so it can't reach the unexported original, which makes the duplication understandable — but CLAUDE.md's "search for an existing helper before adding one" rule is aimed at exactly this, and two copies of a path-layout rule will drift. Either export it from localenv, or add a one-line comment saying the copy is deliberate because the original is unexported.

2. TestSetupLocalServerlessProvision still writes outside the temp dir

Worth a sentence in the doc comment, since the test currently reads as hermetic. The pipeline's provision phase runs uv python install 3.12 (libs/localenv/uv.go:202), and there is no cache-dir override — cmd/environments/sync.go:136 hardcodes os.UserCacheDir() — so the run downloads an interpreter into the developer's shared ~/.local/share/uv/python and populates the real constraint cache.

This is much more benign than the uv installer: it's uv's own managed directory, it's idempotent, and libs/localenv/provision_integration_test.go already does the same. I'm not asking for a change in behaviour, just for the comment to say so, so the next reader doesn't assume t.TempDir() bounds all the writes.

One observation, no action

--serverless-version 5 now resolves to databricks-connect~=18.0.0 upstream — I fetched the live artifact while reviewing. The test only asserts NotEmpty on DBConnectVersion, so it's correctly insulated from the artifact moving. Keeping the assertions loose where the upstream is mutable was the right call and it has already paid off.