Installer_Test (windows_x86) is configured with buildConfig ${{ variables.debugOnPrReleaseOnRolling }} but it downloads ..._Release artifacts and the Helix submission uses /p:Configuration=$(_BuildConfig) (from that buildConfig). On PRs this will likely submit with Configuration=Debug while using Release test assets, which can break helixpublish.proj expectations (payload paths include $(Configuration)). Make the job's buildConfig consistent with the artifacts it downloads (e.g., set buildConfig to release here, or switch downloads/dependsOn to use $(debugOnPrReleaseOnRolling)).

Installer_Test (windows_x64/linux_x64) sets buildConfig: release but downloads artifacts using $(debugOnPrReleaseOnRolling) and depends on the corresponding CoreCLR_Libraries build config. Since Helix submission passes /p:Configuration=$(_BuildConfig), this mismatch will submit the wrong Configuration on PRs (Release) while using Debug artifacts (or vice versa), likely causing missing payload directories. Align this job's buildConfig with the artifact config being downloaded (or adjust the artifact names to always use Release).

Installer_Test (osx_arm64) uses hostedOs: linux and downloads artifacts suffixed with $(debugOnPrReleaseOnRolling), but the matrix buildConfig is hard-coded to release. Because /p:Configuration=$(_BuildConfig) is derived from buildConfig, this can make Helix look for artifacts/tests/host/<os>.<arch>.Release while the downloaded payload is ...Debug on PRs. Make buildConfig match the downloaded artifact configuration.

Setting hostedOs: linux for an osGroup: osx job currently causes conflicting pool definitions in eng/pipelines/common/xplat-setup.yml: the Linux pool block triggers when hostedOs == 'linux' (xplat-setup.yml:168-176) while the macOS vmImage block still triggers based on osGroup alone (xplat-setup.yml:178-186). This will emit both name/demands and vmImage under pool, which Azure Pipelines rejects. To actually move this job to Linux runners, update xplat-setup.yml to gate the macOS pool blocks on hostedOs (or pass an explicit pool: override here instead of hostedOs).

hostedOs: linux is used for an osx Helix submission job, but the current pool selection logic in eng/pipelines/common/xplat-setup.yml will still also select the macOS pool based on osGroup: osx (in addition to the Linux pool selected by hostedOs). This results in an invalid pool object (both vmImage and name/demands). Adjust xplat-setup.yml to make hostedOs override mutually exclusive with osGroup-based macOS pool selection, or set pool: explicitly for this job.

hostedOs: linux is intended to move this osx test-submission job to Linux agents, but eng/pipelines/common/xplat-setup.yml currently selects a macOS pool whenever osGroup is osx regardless of hostedOs. With hostedOs=linux, both the Linux and macOS pool blocks match, producing an invalid pool definition. Update xplat-setup.yml to honor hostedOs as an override (or pass an explicit Linux pool here).

The hostedOs: linux parameter is used here with osx_x64 and osx_arm64 platforms (similarly at lines 1607 and 1998), but eng/pipelines/common/xplat-setup.yml does not guard the macOS pool selection conditions against a hostedOs override. Specifically, lines 179–186 of xplat-setup.yml emit a macOS pool entry whenever osGroup is osx (or other Apple platforms), with no check for hostedOs. Lines 168–176 of that same file correctly check for hostedOs == 'linux' for the Linux pool. When both conditions fire simultaneously, the resulting pool: object contains both name/demands (Linux) and vmImage/os (macOS) fields, which is an invalid Azure Pipelines pool configuration and will likely cause a pipeline failure or still route the agent to a macOS host — defeating the PR's intent. The macOS pool conditions in xplat-setup.yml need to add not(eq(parameters.jobParameters.hostedOs, 'linux')) guards before this configuration can work correctly.

The comment # If intended to send extra steps after regular build add them here. on line 242 is indented inside the ${{ if ne(parameters.skipBuild, true) }}: block, but it refers to the postBuildSteps section that follows at the outer indentation level (line 243). The comment should be moved outside the skipBuild block (to the same indentation level as line 243) to accurately describe the code that follows.

All four new condition: blocks (at lines 1518, 1555, 1592, 1629) omit the >- block scalar indicator that every other multi-line condition in this file uses (e.g. lines 1460, 1478, 1657, etc.). While YAML will still parse these as strings, the style is inconsistent with the rest of the file. These should use condition: >- to match the established pattern throughout runtime.yml.

If we're going to run the installer tests in a job different than where we build them, we should do this build as one step (build clr+libs+libs.tests+host+packs instead of two separate steps).

This is intentionally a separate step as the host+packs are not currently built with the same debug/release flags as the rest of the build.

I would prefer if we used the -hc flag for the installer builds instead of a separate command. It is significantly more difficult for CI investigations and binlog investigations when we have multiple commands (determining which binlog corresponds to which step, accidentally not emitting a binlog or overwriting a binlog) and makes our build scripts much more complicated.

Let's introduce a run-test-job.yml file for running the installer tests on helix instead of adding a skipBuild parameter here.

The "Disk Usage after Build" step on line 233 is not guarded against hostedOs: linux or hostedOs: windows overrides, while the "Disk Usage before Build" block was updated to include such a guard (line 177). When hostedOs: linux is used with an osx osGroup, the "after build" disk usage step would still execute on a Linux agent. While du and df do work on Linux so this won't cause job failures, it is inconsistent with the stated intent of guarding macOS-specific steps against hostedOs overrides, and slightly misleading in pipeline logs. Consider adding not(in(parameters.hostedOs, 'linux', 'windows')) to the "Disk Usage after Build" condition as well, similar to the guard applied to the "before build" block.

(Not in this PR) At some point we should unify between artifacts/tests and artifacts/helix.

Now that we're building all subsets in these jobs, we should rename these jobs to AllSubsets_CoreCLR to be consistent with the other jobs where we build all subsets.