fix(e2e): gate phase 3 VHD-sourced env tolerance on VHD provenance - #9383
Open
Ganeshkumar Ashokavardhanan (ganeshkumarashok) wants to merge 1 commit into
Conversation
… from the source under test ValidateScriptlessPhase3 tolerates diffs confined to GPU_DRIVER_VERSION and GPU_IMAGE_SHA, because provision-config reads them from the components.json baked into the VHD while nbc-cmd generates them from the source under test. That tolerance is only legitimate when the two sides genuinely come from different commits. The VHD builder pipelines run their e2e stage with VHD_BUILD_ID: $(Build.BuildId), so the VHD under test was built from the same commit and both sides must agree exactly -- there the tolerance would mask a real GPU env bug. Gate it on that existing signal: e2e_run.sh exports SIG_VERSION_TAG_NAME=buildId only when VHD_BUILD_ID is set, so config.VHDBuiltFromSourceUnderTest() distinguishes the two cases. The standalone e2e check keeps tolerating the skew and stays unblocked for driver bumps; VHD-build-triggered e2e is now strict again. Every non-VHD-sourced var still fails in both modes, so this keeps full phase 3 coverage on every PR rather than skipping the validator outright.
Ganeshkumar Ashokavardhanan (ganeshkumarashok)
requested review from
Devinwong,
Sri Harsha (SriHarsha001),
Abigail Liang (abigailliang-aks-sig-node),
Abdul Asfari (aboodasfari),
Nishchay (awesomenix),
Ben Brady (benjamin-brady),
Calvin S. (calvin197),
Cameron Meissner (cameronmeissner),
Sylvain Boily (djsly),
fcher,
janenotjung-hue,
Karen Chen (karenychen),
lilypan26,
Mark Ibrahim (mxj220),
Peter Damianov (pdamianov-dev),
Patrick W. Healy (phealy),
r2k1,
Runzhen (runzhen),
Shun Lyu (sinmentis),
sulixu,
Tim Wright (timmy-wright),
Thibault Cohen (titilambert),
Xu Xue (xuexu6666) and
Zachary (zachary-bailey)
as code owners
September 3, 2026 20:27
Contributor
Windows Unit Test Results 3 files 13 suites 43s ⏱️ Results for commit 1622881. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #9244 — base is
ganesh/fix-e2e-phase3-gpu-vhd-skew, so this diff shows only the gate. GitHub will retarget tomainwhen #9244 merges.Addresses Lily's feedback that the fix should key off VHD provenance and not be GPU-specific.
Problem with the tolerance as merged in #9244
#9244 tolerates phase 3 diffs confined to
GPU_DRIVER_VERSION/GPU_IMAGE_SHA, because the two sides have different sources of truth:provision-config/opt/azure/components.json, baked into the VHD (aks-node-controller/app.go:246→getCSEEnv(gpuConfig)→parser/helper.go:564,574)nbc-cmdcse_cmd.sh:159{{GPUDriverVersion}}→pkg/agent/baker.go:1485— compiled from the source under testThat tolerance is only legitimate when the two sides genuinely come from different commits. It is applied unconditionally today, including in the VHD builder pipelines — where the VHD was built from the source under test and the two sides are expected to agree exactly. There, the tolerance would silently mask a real GPU env bug.
Fix
Gate the tolerance on a signal that already exists, rather than adding new plumbing.
.pipelines/scripts/e2e_run.sh:83-86exportsSIG_VERSION_TAG_NAME=buildIdonly whenVHD_BUILD_IDis set, and the VHD builder pipelines setVHD_BUILD_ID: $(Build.BuildId)(.vsts-vhd-builder.yaml:351,.vsts-vhd-builder-release.yaml:941,.build-and-test-windows-vhd-template.yaml:110). So the VHD selected by that tag is the one built earlier in the same run, from the same commit.New
config.Configuration.VHDBuiltFromSourceUnderTest()captures exactly that, andunexpectedEnvCompareDiffVarsnow takes it as a parameter:mainEvery non-VHD-sourced var still fails in both modes.
Why gate the tolerance rather than skip the validator
The alternative discussed was skipping
ValidateScriptlessPhase3entirely on the standalone check. That drops all phase 3 coverage from every PR, since the standalone check is the one that runs on each push. Gating only the tolerance keeps the whole comparison enforced on every PR and restores strictness where it actually matters, so it is strictly stronger.Note on generality
vhdSourcedEnvVarsis a deliberately narrow allowlist rather than a blanket rule.getCSEEnvtakes exactly two inputs that are not derived from the source under test —gpuConfig(these two vars) anddetectContainerdVersion(parser/parser.go:47) — and the GPU pair is the only one sourced from a repo-tracked manifest baked at VHD build time, which is what makes a version bump deadlock. If another such var appears, the failure names it explicitly, which is the discoverable outcome.isExpectedDiffCSEVar(aks-node-controller/app.go:29) remains untouched on purpose: adding these vars there would suppress the production Kusto signal, whereas the artificial condition is E2E's alone.Tests
TestVHDBuiltFromSourceUnderTest— asserts the provenance signal matches whate2e_run.shexports (buildId/branch/ empty)TestUnexpectedEnvCompareDiffVars— now table-driven over both provenance modes, including GPU vars are NOT tolerated when the VHD was built from this sourceTestEnvCompareGPUBumpIsTolerated— the real build 176997071 log line is tolerated on the standalone check and still fails when the VHD is same-sourceBoth directions of the gate were verified load-bearing by mutation:
VHDBuiltFromSourceUnderTestalwaysfalseTestVHDBuiltFromSourceUnderTest/buildId_tag...TestUnexpectedEnvCompareDiffVars/GPU_vars_are_NOT_tolerated...,TestEnvCompareGPUBumpIsToleratedgo vet ./...clean ine2e/; tree restored and byte-identical after mutation runs.