Repository navigation
Move Ubuntu Helix queues to bare 24.04/26.04 VMs - #16
anurag6569201 wants to merge 1 commit into
Conversation
Source PR: dotnet#129863 Source head: 6ec133d
⛔ Shipwright · BlockedRecommendation: do not merge PR #16 · Tier
Findings (7)
Fireworks usage: 11,325 input · 1,088 output · 12,413 total tokens · $0.0032 · 16s · 0 fix iteration(s) Open the Shipwright check for full evidence and the audit bundle. Use |
| value: AzureLinux.3.Amd64 | ||
|
|
||
| # Oldest: Ubuntu 22.04 | ||
| # Oldest: Ubuntu 24.04 |
There was a problem hiding this comment.
Shipwright · CRITICAL
The change removes the explicit container image tag and digest from helix_linux_x64_oldest, helix_linux_x64_oldest_internal, helix_linux_x64_ubuntu_oldest, helix_linux_arm64_latest
Impact: The change removes the explicit container image tag and digest from helix_linux_x64_oldest, helix_linux_x64_oldest_internal, helix_linux_x64_ubuntu_oldest, helix_linux_arm64_latest, and helix_linux_arm64_oldest, replacing them with bare queue names like Ubuntu.2404.Amd64.Open. This silently changes the container image used for the 'oldest' coverage from ubuntu-22.04-helix-amd64 to whatever default image the Ubuntu.2…
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
| # inner and outer loop CoreCLR (general set) | ||
| # Primary distro for all builds | ||
| - (Ubuntu.2604.Amd64.Open)AzureLinux.3.Amd64.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-26.04-helix-amd64@sha256:fc02e7da4a120a698ec895bf09c78c9bf3b41bc93506ad2f737fc0ba30e76ee7 | ||
| - Ubuntu.2604.Amd64.Open |
There was a problem hiding this comment.
Shipwright · CRITICAL
The change removes the explicit @sha256 digest from the primary CoreCLR queue (ubuntu-26.04-helix-amd64@sha256:fc02e7da...) and replaces it with a bare queue name Ubuntu.2604.Amd64
Impact: The change removes the explicit @sha256 digest from the primary CoreCLR queue (ubuntu-26.04-helix-amd64@sha256:fc02e7da...) and replaces it with a bare queue name Ubuntu.2604.Amd64.Open. This eliminates deterministic image pinning for the primary build queue. If the queue's default image is updated or retagged, builds will silently pick up a different image, causing non-reproducible builds and potential breakage tha…
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
| value: (Ubuntu.2604.Amd64.Open)AzureLinux.3.Amd64.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-26.04-helix-webassembly-amd64 | ||
|
|
||
| # Oldest: Ubuntu 22.04 | ||
| # Oldest: Ubuntu 24.04 |
There was a problem hiding this comment.
Shipwright · HIGH
The change removes the explicit image tag from most queue definitions but leaves the browser wasm oldest queue with an explicit tag (ubuntu-24.04-helix-webassembly-amd64) while all
Impact: The change removes the explicit image tag from most queue definitions but leaves the browser wasm oldest queue with an explicit tag (ubuntu-24.04-helix-webassembly-amd64) while all other queues are converted to bare queue names. This inconsistency makes it unclear whether the bare queue names are intended to resolve to the correct image or whether the explicit tag was accidentally left in place. A new contributor wi…
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
| TARGET_TAG="<exact-image-tag>" | ||
| curl -sL https://github.com/dotnet/versions/raw/refs/heads/main/build-info/docker/image-info.dotnet-dotnet-buildtools-prereqs-docker-main.json \ | ||
| | jq -e --arg tag "$TARGET_TAG" 'any(.repos[].images[].platforms[].simpleTags[]; . == $tag)' | ||
| curl -s https://mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list \ |
There was a problem hiding this comment.
Shipwright · HIGH
The SKILL.md change replaces the authoritative image-info JSON check with a direct MCR registry query, but the comment says 'This is in flux' and instructs users to 'Revisit this s
Impact: The SKILL.md change replaces the authoritative image-info JSON check with a direct MCR registry query, but the comment says 'This is in flux' and instructs users to 'Revisit this step once the ORAS solution ships.' This leaves the skill in a knowingly transitional state with no tracking mechanism to ensure the revisit actually happens. A future contributor will not know when the ORAS solution has shipped or how to u…
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
| ### 1. Verify container image availability | ||
|
|
||
| Before making any changes, confirm the **exact target container tag** exists in the [image-info JSON](https://github.com/dotnet/versions/blob/main/build-info/docker/image-info.dotnet-dotnet-buildtools-prereqs-docker-main.json). This file is more authoritative than probing the registry directly and should be the primary source of truth for published `dotnet-buildtools/prereqs` tags: | ||
| Before making any changes, confirm the **exact target container tag** exists by querying the MCR registry directly. The registry is the ground truth for published `dotnet-buildtools/prereqs` tags: |
There was a problem hiding this comment.
Shipwright · HIGH
The SKILL.md change instructs users to query the MCR registry tag list via curl -s https://mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list, but the MCR tags/list endpoint
Impact: The SKILL.md change instructs users to query the MCR registry tag list via curl -s https://mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list, but the MCR tags/list endpoint is known to be paginated and may not return all tags in a single response. The jq query 'any(.tags[]; . == $tag)' will fail to find a valid tag if it is not present in the first page, causing false negatives and blocking legitimate updates.
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
| ### 1. Verify container image availability | ||
|
|
||
| Before making any changes, confirm the **exact target container tag** exists in the [image-info JSON](https://github.com/dotnet/versions/blob/main/build-info/docker/image-info.dotnet-dotnet-buildtools-prereqs-docker-main.json). This file is more authoritative than probing the registry directly and should be the primary source of truth for published `dotnet-buildtools/prereqs` tags: | ||
| Before making any changes, confirm the **exact target container tag** exists by querying the MCR registry directly. The registry is the ground truth for published `dotnet-buildtools/prereqs` tags: |
There was a problem hiding this comment.
Shipwright · HIGH
The SKILL.md change instructs users to pipe the output of curl -s https://mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list directly into jq without any validation of the HT
Impact: The SKILL.md change instructs users to pipe the output of curl -s https://mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list directly into jq without any validation of the HTTP response. If the registry returns an error page, a redirect, or a partial response, the jq query will fail silently or produce incorrect results. This is a supply-chain integrity concern: the skill is now relying on an unauthenticated,…
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
| # inner and outer loop CoreCLR (general set) | ||
| # Primary distro for all builds | ||
| - (Ubuntu.2604.Amd64.Open)AzureLinux.3.Amd64.Open@mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-26.04-helix-amd64@sha256:fc02e7da4a120a698ec895bf09c78c9bf3b41bc93506ad2f737fc0ba30e76ee7 | ||
| - Ubuntu.2604.Amd64.Open |
There was a problem hiding this comment.
Shipwright · HIGH
The change removes the @sha256 digest pinning from the primary CoreCLR queue, which was previously used to ensure the exact image content.
Impact: The change removes the @sha256 digest pinning from the primary CoreCLR queue, which was previously used to ensure the exact image content. Without digest pinning, the build is vulnerable to tag mutation attacks or accidental retagging, where a malicious or compromised image could be substituted for the expected one without any change to the pipeline definition.
Suggested fix: Review the cited evidence, fix the risk if confirmed, and rerun Shipwright.
Now that Ubuntu 26.04 VMs (and 24.04 VMs) are available in Helix, move the Ubuntu Helix coverage off the temporary containers-on-Azure-Linux arrangement and back onto bare Ubuntu VMs, per the Ubuntu 26.04 VM Plan (#125748). This restores the bare-VM testing the policy calls for and retires the 22.04 VMs by moving the oldest slots to 24.04.
Changes
eng/pipelines/helix-platforms.ymlhelix_linux_x64_oldest(+_internal)Ubuntu.2404.Amd64.Open/Ubuntu.2404.Amd64helix_linux_x64_ubuntu_latestUbuntu.2604.Amd64.Openhelix_linux_x64_ubuntu_oldestUbuntu.2404.Amd64.Openhelix_linux_arm64_latestUbuntu.2604.ArmArch.Openhelix_linux_arm64_oldestUbuntu.2404.ArmArch.Openhelix_browser_wasm_oldestubuntu-22.04-helix-webassembly-amd64ubuntu-24.04-helix-webassembly-amd64eng/pipelines/libraries/helix-queues-setup.ymlUbuntu.2604.Amd64.Open.github/skills/update-os-coverage/SKILL.mddotnet/versionsimage-info JSON is in flux pending the ORAS/OCI-artifact migration (dotnet/docker-tools#2142).Notes
Ubuntu.2204.Amd64.Android.*) — no 24.04/26.04 Android Helix queue exists yet (needs dnceng).Ubuntu.2204.ArmArch) insrc/coreclr/scripts/superpmi_collect_setup.py.Reference: OS onboarding guide
Note
This pull request was AI/Copilot-generated.
Source merge-base:
46e1d77bd266c59fe1c80c1903c6221b41ab8476Source head:
6ec133d5cab07e4e2f84102367a7a2be4f64e140