You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mark ordinary Windows Gen2 images, including WS2022 and WS2025, as TrustedLaunchSupported. Derive this from hyperVGeneration in the common Windows build template instead of configuring each image separately. Keep Gen1 and dedicated Trusted Launch behavior unchanged.
Create new capable staging definitions directly. Migrate existing Standard definitions with a verified startsAtVersion boundary, preserving unrelated features and metadata. Reuse already-capable definitions without backfilling an absent boundary; reject invalid or future boundaries.
Add shared-image Trusted Launch scenarios for WS2022 and WS2025. Separate nodes are needed because Secure Boot and vTPM require a different VM security profile from the Standard scenarios. Keep the existing Standard scenarios and dedicated WS2025 Trusted Launch scenario name.
Enable the existing WS2022 Gen2 PR build stage so both shared images are tested against this build's image. ShellSpec covers capability creation, migration, boundary checks, publication metadata, and dedicated-image precedence.
Release handling:
This prepares image capability only. AKS RP's Windows OS eligibility remains unchanged, including its WS2022 Trusted Launch restriction. Production continues selecting dedicated Trusted Launch images by default. Shared WS2025 selection uses the runtime's default-empty version setting; production cutover and dedicated-image retirement remain in work item 40024977.
The Windows VHD-build gate must pass on the current source before merge. Generic Windows E2E uses main-tagged images and does not replace build-specific coverage. No manual cleanup or update of staging definitions is required.
Run:184499433 Failed job/stage/task: e2e / Run AgentBaker E2E / Run AgentBaker E2E
Detective summary: Ubuntu2204_PreProvision_CustomCAFailure hit VMExtensionProvisioningError exit 161 while restarting update_certs.service, matching the recurring CustomCA/update_certs gate signature.
Likely cause / signature: e2e-acl-customca-update-certs-exit161 - Known recurring AgentBaker Linux CSE CustomCA/update_certs provisioning failure.
Confidence: High for known recurring flake: same error string, scenario, VMSS payload, and repair-linked wiki row align; PR 9717 is Windows-image scoped.
Recommended owner/action: No PR action unless this branch intentionally touched Linux CSE; repair item #40042898 tracks the recurring CustomCA failure.
Strongest alternative: PR-specific Windows image regression, but the failing path is Linux CustomCA CSE and predates this PR.
Evidence:build run, build report issues, focused failed job log, PR metadata, and wiki tracker.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Existing capability boundaries are not validated against the current image version, allowing an out-of-order build to proceed without Trusted Launch support.
🟡 Medium Risk — 🔧 Script Logic: This returns success for any existing TrustedLaunchSupported feature without checking its startsAtVersion. If a newer build has already established a later boundary in the shared staging definition, an older/out-of-order build can publish below that boundary; its version remains Standard, so the shared-image Trusted Launch scenario cannot create its VMSS. Preserve the existing boundary, but verify it applies to SIG_IMAGE_VERSION (and fail clearly when it is newer) before returning success.
🧠 Review effort: Balanced
Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.
Detective summary: Run AgentBaker E2E failed because vmssCSE exited with status 161 while restarting update_certs.service with date invalid n/a in CSE output, then cascaded into create-vmss provisioning failures across scenarios.
Likely cause / signature: e2e-vmsscse-update-certs-service-exit-161.
Confidence: High for provisioning/CSE root cause. Timeline isolates failure to e2e/Run AgentBaker E2E, task log captures vmssCSE exit 161 with update_certs.service restart failure and date invalid n/a, and failure occurs before normal scenario validation.
Recommended owner/action: AgentBaker node provisioning/CSE owner should investigate update-certs service path and CSE script handling for missing date values, then revalidate affected image path.
Strongest alternative: PR 9717 product regression, but failure is in VM extension/CSE bootstrap with update_certs.service exit 161 and appears before scenario logic, so PR-caused runtime behavior regression is less likely.
Evidence:build run, failed timeline records for stage e2e/job Run AgentBaker E2E/task Run AgentBaker E2E, task log lines with vmssCSE exit status=161, update_certs.service failed, date invalid n/a, and repeated create vmss failures, source branch refs/pull/9717/merge, and wiki tracker.
Reject migration results with a missing or changed startsAtVersion.
AB#39994891
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1e0bbdd6-8fe8-4eef-a0ff-bc3fdd4b8122
Compare existing boundaries numerically and initialize new shared definitions
with a verified versioned capability before building.
AB#39994891
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1e0bbdd6-8fe8-4eef-a0ff-bc3fdd4b8122
Run the shared-image scenario in both Windows E2E lanes and keep the documentation consistent with the active selectors.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 1e0bbdd6-8fe8-4eef-a0ff-bc3fdd4b8122
Rebased onto main with the CustomData size fixes from #9886 and #9892. No functional changes to this PR; only an annotation for intentional scenario registration in init().
Current source 8650c2e5 now satisfies all required CI checks. The Windows VHD gate and generic Windows E2E both passed after rerunning the failed jobs with restored test-gallery permissions. All Windows image builds and both shared Gen2 Trusted Launch scenarios passed using this build’s images.
Ready for re-review. The separate non-required generic E2E check still has failures; this does not mean every check is green.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Live Windows VHD-build gate results are unavailable, and mocked coverage cannot verify gallery migration safety or WS2022/WS2025 Standard and shared-image Trusted Launch provisioning.
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
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.
What this PR does / why we need it:
Mark ordinary Windows Gen2 images, including WS2022 and WS2025, as
TrustedLaunchSupported. Derive this fromhyperVGenerationin the common Windows build template instead of configuring each image separately. Keep Gen1 and dedicated Trusted Launch behavior unchanged.Create new capable staging definitions directly. Migrate existing Standard definitions with a verified
startsAtVersionboundary, preserving unrelated features and metadata. Reuse already-capable definitions without backfilling an absent boundary; reject invalid or future boundaries.Add shared-image Trusted Launch scenarios for WS2022 and WS2025. Separate nodes are needed because Secure Boot and vTPM require a different VM security profile from the Standard scenarios. Keep the existing Standard scenarios and dedicated WS2025 Trusted Launch scenario name.
Enable the existing WS2022 Gen2 PR build stage so both shared images are tested against this build's image. ShellSpec covers capability creation, migration, boundary checks, publication metadata, and dedicated-image precedence.
Release handling:
This prepares image capability only. AKS RP's Windows OS eligibility remains unchanged, including its WS2022 Trusted Launch restriction. Production continues selecting dedicated Trusted Launch images by default. Shared WS2025 selection uses the runtime's default-empty version setting; production cutover and dedicated-image retirement remain in work item 40024977.
The Windows VHD-build gate must pass on the current source before merge. Generic Windows E2E uses main-tagged images and does not replace build-specific coverage. No manual cleanup or update of staging definitions is required.