Add update-os-coverage skill for Helix queue OS version updates

[richlander]

Note

This PR was generated with assistance from GitHub Copilot CLI.

Add a new Copilot skill (update-os-coverage) that automates updating OS version references in Helix queue definition files.

What it does

The skill guides through the full process of updating OS versions in Helix pipelines:

1. Verify container image availability at dotnet-buildtools-prereqs-docker
2. Check EOL dates via endoflife.date
3. Scan all pipeline files for current references
4. Apply version updates (queue names, image tags, comments)
5. Validate no stale references remain
6. Check release branches for needed updates
7. Cross-reference with supported-os.json in dotnet/core

Key files it operates on

• eng/pipelines/helix-platforms.yml (primary)
• eng/pipelines/libraries/helix-queues-setup.yml
• eng/pipelines/coreclr/templates/helix-queues-setup.yml
• eng/pipelines/installer/helix-queues-setup.yml
• eng/pipelines/common/templates/pipeline-with-resources.yml
• docs/workflow/using-docker.md

References the OS onboarding guide as the authoritative source for policies and processes.

Tested by running the skill against a Fedora 43→44 update — it correctly updated the 2 files with Fedora references, verified image availability, and validated results.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Adds a new Copilot skill (update-os-coverage) to guide/automate updating OS version references across Helix queue and related pipeline definitions (and auditing against the supported OS matrix).

Changes:

• Introduces a new skill document describing an end-to-end workflow for OS version updates in Helix queue definitions.
• Documents inputs, key files, scanning/updating steps, validation steps, and optional cross-branch / supported-os auditing guidance.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

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

[richlander]

Thanks @hoyosjs. Your comments motivated a more critical review on my part. Your call-outs and the additional review made the skill quite a bit better.

[Copilot]

Pull request overview

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

[github-actions]

🤖 Copilot Code Review — PR #126384

Note

This review was generated by Copilot using multi-model analysis (Claude Opus 4.6 primary, with GPT-5.2 and Claude Sonnet 4.5 sub-agent perspectives).

Holistic Assessment

Motivation: This PR adds a new Copilot skill definition to guide an AI agent through the process of updating OS version references in Helix queue pipeline files. This is well-justified — OS version updates are a recurring, mechanical task that touches multiple files with specific naming conventions, and encoding the procedure as a skill ensures consistency and reduces manual effort.

Approach: A single, comprehensive SKILL.md file with a clear step-by-step process (verify image → check EOL → scan references → apply changes → validate → trigger CI → check release branches → cross-reference supported-os → create PR). The document has been through 19+ rounds of iterative refinement and all technical claims have been verified against the actual pipeline files.

Summary: ✅ LGTM. This is a thorough, well-structured skill document. All queue format patterns, naming conventions, _internal counterparts, isExtraPlatformsBuild guards, and Alpine edge casing inconsistencies were verified as accurate against the actual pipeline files. The few suggestions below are minor improvements, not blockers.

---

Detailed Findings

✅ Technical Accuracy — Verified against pipeline files

All core technical claims were cross-checked against the actual source files:

• Queue format pattern (<QueueName>)<HostQueue>@mcr.microsoft.com/dotnet-buildtools/prereqs:<image-tag> matches entries in helix-platforms.yml ✓
• _internal counterparts (e.g., helix_linux_x64_oldest_internal) exist and correctly drop .Open ✓
• All naming convention patterns (Alpine, CentOS Stream, Debian, Fedora, openSUSE, Ubuntu) match actual entries ✓
• isExtraPlatformsBuild guard correctly identified for Debian, Fedora, openSUSE ✓
• Alpine edge casing inconsistency between files (Alpine.edge vs Alpine.Edge) is real ✓
• ARM64 host queue variations (Ubuntu.2204.ArmArch.Open vs AzureLinux.3.Arm64.Open) are accurately described ✓
• Referenced files (docs/project/os-onboarding.md, all pipeline files, lifecycle.md) all exist ✓

✅ Conventions — Consistent with sibling skills

• Frontmatter uses the standard name + description format with > folded block scalar ✓
• No trailing whitespace, file ends with newline per .editorconfig ✓
• AI-generated content disclosure note is present ✓
• Reference section at the end with relevant links ✓

✅ Structure & Completeness — Well-organized workflow

The 9-step process covers the full lifecycle: verification → research → scanning → editing → validation → CI → release branches → cross-referencing → PR creation. The "When NOT to use" section clearly scopes boundaries. The audit mode section provides a separate workflow for coverage auditing.

💡 Scope Clarity — Consider stating "Linux-focused" earlier (flagged by GPT-5.2)

The title and intro say "OS version references" broadly. The Linux-only scope is only clarified later in "When NOT to use" (line 33: "Updating Windows or macOS Helix queues…"). Consider adding a brief "(primarily Linux distros)" qualifier in the opening line to prevent an agent from attempting Windows/macOS queue updates before reaching the exclusion section.

💡 Alpine musl_arm64 Dual-Table Appearance — Minor clarity improvement (flagged by Sonnet 4.5, GPT-5.2 in different forms)

Alpine (versioned) linux_musl_arm64 appears in both the extra-platforms table (line 193) and the default pipeline table (line 204). The explanatory note (line 206) correctly resolves this, but the dual listing may momentarily confuse an agent parsing the tables. Consider annotating the first table entry with an asterisk (e.g., Alpine (versioned)* | linux_musl_arm64) with a footnote, or simply removing it from the first table since coreclr provides default coverage anyway.

💡 Search Strategy — Consider searching by old version tokens too (flagged by GPT-5.2)

Step 3 (line 120) suggests grep -rn -i "<distro>" to find all references. In practice, also searching for the specific old version tokens (e.g., Fedora.43, fedora-43, ubuntu-22.04) would catch version-specific references more reliably, especially in files where the distro name is embedded in longer strings. This is a nice-to-have addendum.

💡 Shallow Clone Detection — Helpful agent hint (flagged by Sonnet 4.5)

Line 231 mentions shallow clones may not have release branches visible and provides a git fetch workaround. Adding git rev-parse --is-shallow-repository as a detection step before the workaround would help an agent know when to apply it.

Generated by Code Review for issue #126384 · ◷