Drop daily quality from release/10.0 and 10.0 channels#5219
Open
LoopedBard3 wants to merge 1 commit into
Open
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the runtime channel configuration used by the repo’s tooling so that .NET 10 jobs no longer request internal-only “daily” servicing SDK builds after .NET 10 GA, avoiding restore/publish failures (e.g., missing runtime packs on public feeds).
Changes:
- Removed
quality: 'daily'from the10.0channel entry. - Removed
quality: 'daily'from therelease/10.0channel entry.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
After .NET 10 GA, `-Quality daily` for these channels resolves to internal-only servicing SDK builds (e.g. 10.0.9) whose matching `Microsoft.NETCore.App.Runtime.<rid>` runtime pack has not yet shipped publicly on the dotnet10 / dotnet-public NuGet feeds. That breaks the CertHelper `--self-contained` publish in run_performance_job.py with NU1102. With no quality specified, dotnet-install hits the public `aka.ms/dotnet/10.0/` GA endpoint (currently SDK 10.0.203 / runtime 10.0.7), whose runtime packs are publicly available, so the publish step succeeds. main (net11) and nativeaot* channels are unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
740b22c to
425e5c9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
After .NET 10 GA,
-Quality dailyon therelease/10.0(and bare10.0) channels resolves to internal-only servicing SDK builds (e.g. SDK 10.0.9-flavored bits) whose matchingMicrosoft.NETCore.App.Runtime.<rid>runtime pack has not yet shipped publicly on thedotnet10/dotnet-publicNuGet feeds.That breaks the CertHelper
--self-containedpublish inrun_performance_job.py:(Example failing run: https://dev.azure.com/dnceng/internal/_build/results?buildId=2969704)
Fix
Remove
'quality': 'daily'from therelease/10.0and10.0entries inchannel_map.py. With no quality specified,dotnet.pyomits the-Qualityflag (it already handlesNonecorrectly), sodotnet-installhits the publicaka.ms/dotnet/10.0/GA endpoint — currently SDK10.0.203/ runtime10.0.7— whose runtime packs are publicly available, so the publish step succeeds and the SDK rolls forward automatically with each public servicing release.What's unchanged
main(net11) stays onquality: daily— net11 is pre-release and its dailies are public, so that's still the right choice.nativeaot10.0is unchanged in this PR but has the same shape (branch: 10.0,quality: daily) and would hit the same NU1102 if exercised today. Happy to fold it in if reviewers prefer; left out for now since it's not the failing path.sdk-perf-jobs.yml; this is purely a fix for runs that already userelease/10.0/10.0.Trade-off
The net10 leg now baselines against the latest publicly-released servicing build (e.g. runtime 10.0.7) instead of the freshest internal daily. For BDN regression work this is actually the more reproducible baseline; runtime perf jobs that build their own Core_Root use the SDK only as build-time tooling, so a slightly older public SDK is fine.
Validation
Verified manually by triggering perf runs from this branch against
release/10.0and confirming the CertHelper publish succeeds and the runs upload results end-to-end.