Skip to content

Fix CI: replace decommissioned vs2022preview pool image [vs17.12] - #13541

Merged
SimaTian merged 1 commit into
dotnet:vs17.12from
SimaTian:fix/ci-image-vs17.12
Apr 15, 2026
Merged

SimaTian merged 1 commit into
dotnet:vs17.12from
SimaTian:fix/ci-image-vs17.12

Conversation

@SimaTian

Copy link
Copy Markdown
Contributor

Problem

The FullReleaseOnWindows CI job uses the windows.vs2022preview.amd64.open image on the NetCore-Public pool. This image has been decommissioned by the dnceng infrastructure team (see dotnet/dnceng#6396), causing the job to hang waiting for an agent and eventually time out after 3 hours.

This has been broken since approximately Feb-Mar 2026 (last known working PR: Jan 26, first known broken: Apr 6).

Fix

Replace windows.vs2022preview.amd64.open with windows.vs2022.amd64.open (the stable VS 2022 image that is actively maintained). This is the same image used by the vs17.8 servicing branch which continues to work.

The main branch uses windows.vs2026preview.scout.amd64.open but that targets a newer VS version not appropriate for 17.x servicing branches.

Changes

  • .vsts-dotnet-ci.yml: Update pool image demand for FullReleaseOnWindows job
  • eng/Versions.props: Bump patch version (required for servicing branch PRs)

The windows.vs2022preview.amd64.open image on the NetCore-Public pool
has been decommissioned, causing the FullReleaseOnWindows job to hang
and time out. Replace with the actively maintained windows.vs2022.amd64.open
stable image.

Bump version 17.12.58 -> 17.12.59 (required for servicing branch PRs).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings April 15, 2026 09:02
@SimaTian
SimaTian requested a review from a team as a code owner April 15, 2026 09:02

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the servicing-branch CI configuration to stop using a decommissioned Windows VS2022 Preview agent image and bumps the patch version to satisfy servicing-branch requirements.

Changes:

  • Switch FullReleaseOnWindows (public pool) from windows.vs2022preview.amd64.open to windows.vs2022.amd64.open to restore agent availability.
  • Bump VersionPrefix from 17.12.58 to 17.12.59.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
eng/Versions.props Patch version bump for the servicing branch.
.vsts-dotnet-ci.yml Update pool demand to use the maintained VS2022 stable image for the affected CI job.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review Summary — PR #13541

Reviewed: Both changes in .vsts-dotnet-ci.yml and eng/Versions.props.

CI Pool Image Change (windows.vs2022previewwindows.vs2022)

Looks correct. This is the only ImageOverride reference in .vsts-dotnet-ci.yml, and no other files in the repo reference vs2022preview — so there are no missed occurrences. The FullReleaseOnWindows job for the public pool now targets the stable VS 2022 image, which is consistent with the other pipeline files (e.g., eng/common/core-templates/post-build/post-build.yml already uses windows.vs2022.amd64).

For a servicing branch (vs17.12), using the stable image rather than preview is the right call — it reduces risk of unexpected toolchain changes destabilizing release builds and aligns with the principle of using well-known, stable infrastructure for servicing.

Version Bump (17.12.58 → 17.12.59)

Standard patch-level servicing bump. Only the patch component changes, DotNetFinalVersionKind remains release, and no other version-related properties are affected. This is consistent with the expected servicing workflow.

No Issues Found

Both changes are straightforward, low-risk, and consistent with the repo's conventions. No functional, correctness, or security concerns identified.

Note

🔒 Integrity filter blocked 1 item

The following item were blocked because they don't meet the GitHub integrity level.

  • #13541 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Expert Code Review (on open) for issue #13541 · ● 1.2M

@ViktorHofer ViktorHofer left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. We shouldn't be using the preview windows pool in servicing.

@rainersigwald

Copy link
Copy Markdown
Member

This is the same image used by the vs17.8 servicing branch which continues to work.

Why didn't the image change merge forward?

@SimaTian
SimaTian merged commit fd8bd51 into dotnet:vs17.12 Apr 15, 2026
20 checks passed
@SimaTian

Copy link
Copy Markdown
Contributor Author

This is the same image used by the vs17.8 servicing branch which continues to work.

Why didn't the image change merge forward?

If the bot is to be trusted, this is a series of issues that was bubbling for a while:

  1. Commit 4429ce9 ("Run release job on preview VS") introduced vs2022preview image long ago on multiple branches
  2. vs17.8 was never affected (always used stable vs2022)
  3. vs17.11 was fixed on Mar 16, 2026 via Maestro arcade update [vs17.11] Update dependencies from dotnet/arcade #13278 — the arcade SDK itself carries the image change
  4. The inter-branch merge workflow fired correctly after the vs17.11 push, found config vs17.11 → vs17.12, and tried to
    merge 5 commits…
  5. …but skipped PR creation because ALL 5 commits were from @dotnet-maestro[bot]. The arcade script's bot-commit filter
    silently blocked the forward merge.
  6. Maestro also tried independently — PR [vs17.12] Update dependencies from dotnet/arcade #13227 (arcade update directly to vs17.12, open since Feb 9, 2026) contains
    the same image fix. But it's been stuck because CI fails on it (the FullReleaseOnWindows job still times out, likely
    because AzDO reads the pipeline YAML from the base branch, not the PR).

So it's not really "stalled" — both mechanisms tried and both got blocked: the merge-forward by a bot-commit filter, and
the direct Maestro update by the broken CI it's trying to fix. A classic chicken-and-egg.

@ViktorHofer

Copy link
Copy Markdown
Member

…but skipped PR creation because ALL 5 commits were from @dotnet-maestro[bot]. The arcade script's bot-commit filter
silently blocked the forward merge.

Yes that's a known issue and it's super annoying. It affects multiple repos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants