update-os-coverage

Update OS version references in Helix queue definitions for .NET CI testing.

1.2k|337|Updated Oct 13, 2022
One-click install
npx skills add https://github.com/dotnet/dotnet --skill update-os-coverage
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: update-os-coverage
Source: https://github.com/dotnet/dotnet/tree/main/src/runtime/.github/skills/update-os-coverage
Command: npx skills add https://github.com/dotnet/dotnet --skill update-os-coverage

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Keeping .NET runtime CI testing aligned with the OS lifecycle is tedious and error-prone: EOL distro versions linger in Helix queue definitions, new releases are not added for coverage, and version references are scattered across multiple pipeline YAML files. This Skill guides the full update workflow so queue definitions stay consistent with the supported-os matrix.

Core Features & Use Cases

  • Version Updates: Add new OS versions, replace EOL versions, or upgrade "oldest"/"latest" slots across helix-platforms.yml and the libraries, coreclr, and installer helix-queues-setup.yml files.
  • Registry Verification: Confirms exact container image tags exist in the MCR registry (mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list) before making changes.
  • Audit Mode: Compares all Helix queue references against supported-os.json in dotnet/core and endoflife.date lifecycle data, reporting a table of recommended changes.
  • Use Case: Fedora 44 reaches GA and Fedora 42 approaches EOL. Ask the Skill to update Fedora coverage; it verifies the fedora-44-helix-amd64 image exists, updates all queue strings and image tags, checks release branches, and drafts a PR with EOL dates and CI pipeline requirements.

Quick Start

Ask the assistant to update Fedora to version 44 in the Helix queue definitions and verify the container image exists in the MCR registry.

Frequently Asked Questions about update-os-coverage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I update a Helix queue OS version in dotnet/runtime?

Verify the new container image tag exists in the MCR registry, then update version references in eng/pipelines/helix-platforms.yml and the libraries, coreclr, and installer helix-queues-setup.yml files. Preserve existing queue naming patterns and host queues, then validate no stale references remain.

How do I check if a dotnet-buildtools prereqs container image exists?

Query the MCR registry tag list at mcr.microsoft.com/v2/dotnet-buildtools/prereqs/tags/list and check for the exact tag. The image-info JSON in dotnet/versions is only a secondary cross-check because it can be stale during the ORAS publishing transition.

When should I not use this OS coverage update workflow?

Do not use it to create new container images (that belongs to dotnet-buildtools-prereqs-docker), update supported-os.json (handled in dotnet/core), request new Helix VM queues (dotnet/dnceng), or update Windows and macOS queues, which require dnceng coordination.

Does updating Helix queues require running extra CI pipelines?

Some distros like Fedora, openSUSE, and Alpine edge are only exercised by the runtime-extra-platforms pipeline. After creating a PR, trigger it with "/azp run runtime-extra-platforms" if your changes affect distros not covered by the default runtime pipeline.

Should release branches get the same OS version updates as main?

Release branches should be updated only when the old version is EOL or approaching EOL and the branch will be serviced longer than the old version's support. Prefer GA, already-supported versions on servicing branches, and submit release branch updates as separate PRs.