[VPEX][11] Default serverless target to v5#5962
Conversation
rugpanov
changed the title
Integration test reportCommit: 846170a
8 interesting tests: 4 RECOVERED, 4 SKIP
Top 10 slowest tests (at least 2 minutes):
|
Per the [P0] CLI Changes spec, the serverless stand-in used when the source does not pin a version is now serverless-v5 (was v4). This applies only to the fallback cases — a serverless job with no recorded version, and a bundle that records 'serverless' without a version. Explicitly passing --serverless-version is unaffected. Introduce defaultServerlessVersion in envkey.go and use it at both fallback sites so the default lives in one place. VS Code resolves the real version itself and passes --serverless-version explicitly, so this fallback applies only when the version is genuinely unknown. Co-authored-by: Isaac
179ea18 to
846170a
Compare
anton-107
left a comment
anton-107
left a comment
There was a problem hiding this comment.
Reviewed as part of the full stack (#5960–#5965). Consolidating the default into defaultServerlessVersion and using it at both fallback sites is the right move. Approving.
Two things to fold in:
-
[medium] The v5 default has no end-to-end coverage — and nothing verifies
serverless-v5is actually published. No acceptance test exercises the default-serverless path (unpinned serverless job / bundle-serverless), and no test server servesserverless/serverless-v5/pyproject.toml(only v3/v4 exist underacceptance/localenv/*/test.toml). The two unit tests that "cover" the default (target_test.go:100,:153) assert against"serverless/serverless-"+defaultServerlessVersion— i.e. they compare the code to the same constant it uses, so they'd pass for any value. Net: ifserverless-v5isn't yet a published key in the (not-yet-public) constraints repo, a real user hitting the default getsE_ENV_UNSUPPORTEDat fetch and no test in the repo would catch it. Since "default to v5" is the whole point of this PR, an acceptance case that servesserverless-v5and drives the default path would be valuable. -
[low] Stale
v4comments left behind. This PR moved the default to v5 but two code comments still say v4:cmd/environments/compute.go:78("falls back to v4 in ResolveTarget") and:116("the v4 fallback …"), plus the acceptance commentacceptance/localenv/job-serverless-check/test.toml:7("rather than defaulting to v4"). A reader reasoning about the unpinned-job path is told v4 when it's now v5.
Reviewed with AI assistance (build + unit tests + adversarial verification against the checked-out top of stack).
3 participants
Stacked on #5961 (
--cluster-name) → #5960 → #5959.What
Per the
[P0] CLI Changesspec, the serverless stand-in used when the source does not pin a version is nowserverless-v5(wasv4).Applies only to the fallback cases:
--job-idwhose environment records no version, andserverlesswithout a version.Explicitly passing
--serverless-version <vN>is unaffected.Changes
defaultServerlessVersion = "v5"inenvkey.go, used at both fallback sites intarget.goso the default lives in one place.No acceptance goldens change: all serverless acceptance tests pass
--serverless-version v4explicitly, so none exercise the default path.Note
VS Code resolves the real serverless version itself and passes
--serverless-versionexplicitly (spec §63), so this fallback is only hit when the version is genuinely unknown — but v5 is now the correct stand-in per spec.This pull request and its description were written by Isaac.