ci: watch nuget.org for platform packages this umbrella has fallen be… - #6
Merged
Conversation
…hind
An umbrella pins its platform binding packages by exact version, by hand. When
a platform repository publishes, nothing said so: the umbrella kept resolving
the older binding and consumers kept getting it, silently, until somebody
noticed. The native SDKs were watched; this authors own packages, the ones
actually most likely to move, were the blind spot - the manifest comment said
as much in so many words.
Adds a `nuget` check kind to the shared build/check-upstream.sh and a row per
pinned platform package, so the existing daily upstream-drift workflow reports
them alongside the native SDKs, with the same open/comment/close issue
lifecycle. Discovery is the flat containers version index; confirmation is the
.nupkg beside it, which is a ZIP, so the existing PK magic-byte check applies
unchanged.
Deliberately asymmetric, because the two directions mean opposite things:
pin behind published the umbrella is stale. This is the finding.
pin ahead of published the platform release is not out yet, which is the
normal mid-flight state of a release train. Logged,
never filed, or every train would open an issue on
its way through.
prerelease pin checked first and always reported: `sort -V` ranks
2.34.1.4-beta.7.3 above 2.34.1.4, so it would
otherwise read as "ahead" and say nothing, while a
released umbrella depending on a beta is a defect.
Verified against live nuget.org rather than reasoned about - a three-case
fixture over a real package covering behind, equal and ahead, plus a run of
every umbrella. The run found four genuine stale pins, listed in the pull
request.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
…hind
An umbrella pins its platform binding packages by exact version, by hand. When a platform repository publishes, nothing said so: the umbrella kept resolving the older binding and consumers kept getting it, silently, until somebody noticed. The native SDKs were watched; this authors own packages, the ones actually most likely to move, were the blind spot - the manifest comment said as much in so many words.
Adds a
nugetcheck kind to the shared build/check-upstream.sh and a row per pinned platform package, so the existing daily upstream-drift workflow reports them alongside the native SDKs, with the same open/comment/close issue lifecycle. Discovery is the flat containers version index; confirmation is the .nupkg beside it, which is a ZIP, so the existing PK magic-byte check applies unchanged.Deliberately asymmetric, because the two directions mean opposite things:
pin behind published the umbrella is stale. This is the finding.
pin ahead of published the platform release is not out yet, which is the
normal mid-flight state of a release train. Logged,
never filed, or every train would open an issue on
its way through.
prerelease pin checked first and always reported:
sort -Vranks2.34.1.4-beta.7.3 above 2.34.1.4, so it would
otherwise read as "ahead" and say nothing, while a
released umbrella depending on a beta is a defect.
Verified against live nuget.org rather than reasoned about - a three-case fixture over a real package covering behind, equal and ahead, plus a run of every umbrella. The run found four genuine stale pins, listed in the pull request.