Flag new major versions of NuGets we don't support#8800
Merged
Conversation
Collaborator
Author
|
@codex review |
github-actions
Bot
added
the
area:builds
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c1db7f8138
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+223
to
+226
| foreach (var candidate in QueriedVersions[packageName]) | ||
| { | ||
| if (NuGetVersion.TryParse(candidate.Version, out var parsed) | ||
| && (latestAvailable is null || parsed > latestAvailable)) |
There was a problem hiding this comment.
When a package owner unlists/yanks an unsupported major, this loop still considers that version because QueriedVersions is populated by GetAllNugetPackageVersions, which queries NuGet metadata with includeUnlisted: true. That can keep or open scheduled pending-major PRs for versions that are no longer advertised as the latest available package, so the latest-major calculation should either query listed versions separately or retain/list-filter the metadata before adding MajorAvailableEntry.
Useful? React with 👍 / 👎.
BenchmarksBenchmark execution time: 2026-06-30 15:31:51 Comparing candidate commit da7fd70 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 72 metrics, 0 unstable metrics, 60 known flaky benchmarks, 66 flaky benchmarks without significant changes.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8800) and master. ✅ No regressions detected - check the details below Full Metrics ComparisonFakeDbCommand
HttpMessageHandler
Comparison explanationExecution-time benchmarks measure the whole time it takes to execute a program, and are intended to measure the one-off costs. Cases where the execution time results for the PR are worse than latest master results are highlighted in **red**. The following thresholds were used for comparing the execution times:
Note that these results are based on a single point-in-time result for each branch. For full results, see the dashboard. Graphs show the p99 interval based on the mean and StdDev of the test run, as well as the mean value of the run (shown as a diamond below the graph). Duration chartsFakeDbCommand (.NET Framework 4.8)gantt
title Execution time (ms) FakeDbCommand (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (73ms) : 68, 77
master - mean (69ms) : 67, 71
section Bailout
This PR (8800) - mean (77ms) : 72, 81
master - mean (73ms) : 72, 75
section CallTarget+Inlining+NGEN
This PR (8800) - mean (1,083ms) : 1033, 1133
master - mean (1,080ms) : 1036, 1125
FakeDbCommand (.NET Core 3.1)gantt
title Execution time (ms) FakeDbCommand (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (114ms) : 108, 121
master - mean (109ms) : 106, 111
section Bailout
This PR (8800) - mean (111ms) : 107, 115
master - mean (110ms) : 108, 112
section CallTarget+Inlining+NGEN
This PR (8800) - mean (776ms) : 757, 796
master - mean (777ms) : 755, 799
FakeDbCommand (.NET 6)gantt
title Execution time (ms) FakeDbCommand (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (100ms) : 95, 105
master - mean (97ms) : 94, 99
section Bailout
This PR (8800) - mean (98ms) : 95, 100
master - mean (97ms) : 95, 99
section CallTarget+Inlining+NGEN
This PR (8800) - mean (934ms) : 877, 992
master - mean (937ms) : 899, 975
FakeDbCommand (.NET 8)gantt
title Execution time (ms) FakeDbCommand (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (95ms) : 92, 97
master - mean (98ms) : 93, 104
section Bailout
This PR (8800) - mean (99ms) : 92, 105
master - mean (99ms) : 95, 103
section CallTarget+Inlining+NGEN
This PR (8800) - mean (820ms) : 779, 861
master - mean (812ms) : 770, 855
HttpMessageHandler (.NET Framework 4.8)gantt
title Execution time (ms) HttpMessageHandler (.NET Framework 4.8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (207ms) : 201, 212
master - mean (204ms) : 199, 209
section Bailout
This PR (8800) - mean (211ms) : 208, 215
master - mean (207ms) : 203, 212
section CallTarget+Inlining+NGEN
This PR (8800) - mean (1,227ms) : 1192, 1262
master - mean (1,211ms) : 1168, 1254
HttpMessageHandler (.NET Core 3.1)gantt
title Execution time (ms) HttpMessageHandler (.NET Core 3.1)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (294ms) : 287, 300
master - mean (291ms) : 286, 296
section Bailout
This PR (8800) - mean (297ms) : 292, 303
master - mean (290ms) : 285, 296
section CallTarget+Inlining+NGEN
This PR (8800) - mean (993ms) : 967, 1019
master - mean (974ms) : 954, 993
HttpMessageHandler (.NET 6)gantt
title Execution time (ms) HttpMessageHandler (.NET 6)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (289ms) : 283, 295
master - mean (286ms) : 281, 291
section Bailout
This PR (8800) - mean (290ms) : 285, 295
master - mean (285ms) : 278, 291
section CallTarget+Inlining+NGEN
This PR (8800) - mean (1,182ms) : 1139, 1225
master - mean (1,173ms) : 1130, 1216
HttpMessageHandler (.NET 8)gantt
title Execution time (ms) HttpMessageHandler (.NET 8)
dateFormat x
axisFormat %Q
todayMarker off
section Baseline
This PR (8800) - mean (287ms) : 278, 297
master - mean (285ms) : 280, 289
section Bailout
This PR (8800) - mean (290ms) : 284, 295
master - mean (287ms) : 280, 294
section CallTarget+Inlining+NGEN
This PR (8800) - mean (1,063ms) : 1007, 1118
master - mean (1,054ms) : 1007, 1102
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This comment has been minimized.
This comment has been minimized.
andrewlock
approved these changes
Jun 19, 2026
andrewlock
left a comment
andrewlock
left a comment
Member
There was a problem hiding this comment.
If it works, it LGTM, other than I'm not sure the pending_major_versions doc is necessary. If possible, I think including these in supported_versions.json would be better. And if that's too difficult, outputting a json file instead I think would be better.
Triggered a run against this branch here, just to see how it does 🤞
We used to get this by the dependabot honey pot csproj files having their comments updated, but we have lost this and it was missed. Adding a new tracked file as I wasn't actually sure how to _guarantee_ that we would have changes somewhere that would trigger the PR to open, but granted that is if and only if we don't have any bumps whatsoever, which may not actually happen.
- Exclude unlisted/yanked versions from "latest available" - Key tracked file on major form (2.x) to avoid patch churn - Flag every integration sharing a package ceiling, not just one - Sort report rows by integration name for determinism
andrewlock
force-pushed
the
steven/fix-major-version-package-reporting
branch
from
June 30, 2026 14:37
f4b6b10 to
da7fd70
Compare
Member
|
I pushed a few extra changes:
For example, the following is what you get if you rebase on top of Package Version Updates
New Major Versions AvailableThese have a new major outside our supported range. Review whether to widen the
Package Version Cooldown ReportThe following versions were published less than 2 days ago and have been ignored.
|
andrewlock
marked this pull request as ready for review
June 30, 2026 14:42
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da7fd70277
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+420
to
+421
| var reportPath = TemporaryDirectory / "bump_report.md"; | ||
| await versionGenerator.BumpReport.SaveToFile(reportPath); |
There was a problem hiding this comment.
When the only output is MajorAvailableEntries, this writes the report only to .nuke/temp/bump_report.md, and .nuke/temp/ is ignored by the repo. The scheduled .github/workflows/auto_bump_test_package_versions.yml then calls peter-evans/create-pull-request, which only creates a PR when the checkout has a diff (per the action docs: https://github.com/peter-evans/create-pull-request#action-behaviour). If an unsupported major is already reflected in supported_versions.json from a previous run or a merged bot PR, a later run produces only this ignored temp report, so no PR is opened and the pending unsupported major stops being flagged; persist the pending-major marker in tracked output or otherwise dirty the checkout when these entries exist.
Useful? React with 👍 / 👎.
bouwkast
enabled auto-merge (squash)
June 30, 2026 18:46
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
2 participants
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.
Summary of changes
Detects and flags whenever we have a new major version of an instrumented NuGet package that we don't yet support.
Reason for change
We used to get this previously when the dependabot projects would have their comments updated noting the latest version and we would then manually follow up on them. But with that removed this was accidentally lost.
Implementation details
Grabs new unsupported major versions and reports them in a new table the cooldown report.
Test coverage
Other details
Since we don't technically update the generated files I figured that it would be best to include a new tracked file for the "unsupported" major versions. Pretty small edge case, but if for some reason that there are no updates besides major versions we wouldn't open the PR.
We could go and re-use the
supported_versions.jsonfile but unsure on the plans with that honestly.