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
{{ message }}
Repository navigation
feat: support a shared Windows 2025 Gen2 image - #9717
Build windows-2025-gen2 as TrustedLaunchSupported without enabling Trusted Launch on the build VM. Standard and Trusted Launch nodes can then use the same image.
Reuse already-capable staging definitions without startsAtVersion without updating or recreating them, matching the existing Linux staging behavior. When a boundary is present, preserve it only when valid and numerically at or below the build version; malformed, empty, or future boundaries fail the build. New capability migrations still establish and verify the exact persisted boundary, preserving other features and metadata.
Create genuinely new shared staging definitions directly as TrustedLaunchSupported. Only existing Standard definitions need a bounded capability update.
Add Windows2025Gen2_TrustedLaunch_SharedImage because its VM security profile differs from the standard scenario. Retain the dedicated TL build and existing scenario name.
Run the shared scenario in both the VHD-build gate, using that build's image, and the generic Windows E2E job, using the main-tagged test image.
Focused ShellSpec covers direct capable creation, existing-definition migration/read-back, no-backfill reuse, metadata, and dedicated precedence. Previous VHD-build and generic Windows E2E gates passed on the earlier source head; revised-source CI must run after publication.
Release handling:
No cleanup or manual update of shared test definitions is required. The Windows VHD-build gate must pass using this build's image before merge.
This change prepares shared-image capability. Production continues to select dedicated TL images. The runtime uses one default-empty version setting for approved shared-image testing. Formal production cutover and dedicated-image retirement remain in work item 40024977.
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.
The reason will be displayed to describe this comment to others. Learn more.
How is this init func invoked? And given how the TL VHD will be retired in the future, it might make life easier just to duplicate the block - then we can delete the old one later.
The reason will be displayed to describe this comment to others. Learn more.
This seems strange - removing the TrustedLaunchSupported for Windows SIGs.
But it's made me wonder - maybe we should set TrustedLaunchSupported for all gen2 SIGs. Even for WS2022. We block trusted launch for WS2022 in aks-rp, so that's not an issue. I'm not sure if there are other implications tho.
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
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The image-capability migration needs human confirmation that the mandatory Windows VHD-build gate passes on the revised source, which was not verified here.
No open issues 🎉
Review effort: Balanced
This branch has not been deployed
No deployments
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:
Build
windows-2025-gen2asTrustedLaunchSupportedwithout enabling Trusted Launch on the build VM. Standard and Trusted Launch nodes can then use the same image.Reuse already-capable staging definitions without
startsAtVersionwithout updating or recreating them, matching the existing Linux staging behavior. When a boundary is present, preserve it only when valid and numerically at or below the build version; malformed, empty, or future boundaries fail the build. New capability migrations still establish and verify the exact persisted boundary, preserving other features and metadata.Create genuinely new shared staging definitions directly as
TrustedLaunchSupported. Only existing Standard definitions need a bounded capability update.Add
Windows2025Gen2_TrustedLaunch_SharedImagebecause its VM security profile differs from the standard scenario. Retain the dedicated TL build and existing scenario name.Run the shared scenario in both the VHD-build gate, using that build's image, and the generic Windows E2E job, using the main-tagged test image.
Focused ShellSpec covers direct capable creation, existing-definition migration/read-back, no-backfill reuse, metadata, and dedicated precedence. Previous VHD-build and generic Windows E2E gates passed on the earlier source head; revised-source CI must run after publication.
Release handling:
No cleanup or manual update of shared test definitions is required. The Windows VHD-build gate must pass using this build's image before merge.
This change prepares shared-image capability. Production continues to select dedicated TL images. The runtime uses one default-empty version setting for approved shared-image testing. Formal production cutover and dedicated-image retirement remain in work item 40024977.