Use rolling Windows Helix queue for CoreCLR

[chcosta]

[Just testing the new queue]

[azure-pipelines]

Azure Pipelines:
Successfully started running 5 pipeline(s).
11 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

This PR updates CoreCLR Helix configuration to use the rolling public Windows AMD64 queue name (Windows.Amd64.Open) instead of the version-pinned queue (Windows.10.Amd64.Open), and keeps the SuperPMI collection setup script aligned with the pipeline template.

Changes:

• Switch CoreCLR public Windows x64 Helix queue from Windows.10.Amd64.Open to Windows.Amd64.Open.
• Switch CoreCLR public Windows x86 Helix queue from Windows.10.Amd64.Open to Windows.Amd64.Open.
• Update SuperPMI collection setup to use the same rolling Windows AMD64 queue.

Reviewed changes

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

File	Description
src/coreclr/scripts/superpmi_collect_setup.py	Updates the public Windows AMD64 queue used for SuperPMI collection setup.
eng/pipelines/coreclr/templates/helix-queues-setup.yml	Updates CoreCLR Helix queue selection for public Windows x64/x86 to the rolling queue name.

[Copilot]

Pull request overview

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

Suppressed comments (2)

src/coreclr/scripts/superpmi_collect_setup.py:472

• The script now moves public Windows x64 collections to the rolling queue (Windows.Amd64.Open.rt), but the non-public (internal) Windows path still hard-codes a Windows.10.* queue (Windows.10.Amd64.X86.Rt). Since this script sets the pipeline Queue variable, internal SuperPMI collections will continue to run on a different (pinned) OS/queue than the updated rolling queues used elsewhere, which makes it hard to reason about behavior and can lead to unexpected queue drift.

Please either (a) update the internal Windows x64 queue mapping to the corresponding rolling queue, or (b) add an explicit comment explaining why SuperPMI internal collections must stay on the pinned Windows.10.* X86 queue so future queue changes don’t diverge silently.

        if platform_name == "windows":
            if arch == "arm64": # public windows_arm64
                helix_queue = "Windows.11.Arm64.Open"
            else: # public windows_x64
                helix_queue = "Windows.Amd64.Open.rt"

eng/pipelines/coreclr/templates/helix-queues-setup.yml:154

• This template updates internal Windows x64 to Windows.Amd64.rt, but internal Windows x86 remains on the pinned Windows.10.Amd64.X86.Rt queue a few lines below. If the intent is to move CoreCLR Windows coverage to the rolling queues, consider aligning the internal x86 queue as well (or add a short note here explaining why x86 stays pinned while x64 rolls) to avoid future confusion and piecemeal queue drift.

        - Windows.Amd64.Open.rt
      - ${{ if and(eq(variables['System.TeamProject'], 'public'), eq(parameters.jobParameters.helixQueueGroup, 'cet')) }}:
        - Windows.11.Amd64.Cet.Open
      - ${{ if eq(variables['System.TeamProject'], 'internal') }}:
        - Windows.Amd64.rt