Bump Proc to 0.14.0, fix release-notes CLI invocation, harden tool restore - #44
Merged
Merged
Conversation
…store Proc was pinned at 0.9.1; the build scripts assumed 0.14+ semantics elsewhere (no shell expansion, throws on failure) so this just catches the pin up. release-notes was recently ported to a new Argh-based CLI (0.11.0): bare invocation is gone (needs an explicit `generate`/`create-release` command first) and `--label` takes a single `key=value` token instead of two. The build script still called the old CLI shape, which would have broken the next tagged release. Bumped the pinned version and fixed both call sites to match, verified against the real 0.11.0 package. Also retries `dotnet tool restore` once on failure: dotnet/sdk#53783 causes cold-cache restores of 2+ RID-specific tool packages (all of ours now are) to misattribute one package's DotnetToolSettings.xml to another. A retry always succeeds since the resolver cache is warm afterward. Co-authored-by: Cursor <cursoragent@cursor.com>
The plain "assembly-differ" package id is a DotnetToolSettings.xml v2 shim that maps RIDs to per-RID sub-packages (see generatePackages) - it ships no managed assembly of its own, so diffing against it finds 0 assemblies. This would have broken "Inspect public API changes" on the next release, the same way it just did in release-notes: https://github.com/nullean/release-notes/actions/runs/33674817669/job/100397363448 The portable, signed managed build lives in "assembly-differ.any" instead; point previous-nuget at that. Co-authored-by: Cursor <cursoragent@cursor.com>
Contributor
Author
|
Also fixed |
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.
Summary
Procbuild-script dependency from 0.9.1 to 0.14.0 (latest), matching the semantics (no shell expansion, throws on failure) already assumed elsewhere.release-noteswas ported to a new Argh-based CLI in 0.11.0 (bare invocation dropped,--labelnow takes a singlekey=valuetoken). This repo's build script still called the old shape. Bumped the pin to 0.11.0 and fixedgeneratereleasenotes/createreleaseongithubto match - would have broken the next tagged release.dotnet tool restorenow retries once on failure: dotnet/sdk#53783 causes cold-cache restores of 2+ RID-specific tool packages (all of ours are, now) to misattribute one package'sDotnetToolSettings.xmlto another. A retry always succeeds since the cache is warm afterward.Test plan
dotnet build build/scripts/scripts.fsproj -c Releasesucceeds../build.sh generatereleasenotes -s trueruns against the realrelease-notes0.11.0 package and produces correct output.Made with Cursor