From c84174ea74951261f1d929696220a36b0b4e98af Mon Sep 17 00:00:00 2001 From: Martijn Laarman Date: Wed, 2 Sep 2026 21:40:21 +0200 Subject: [PATCH 1/2] Bump Proc to 0.14.0, retry dotnet tool restore once on failure Proc was pinned at 0.9.1; catches it up to 0.14.0 to match the semantics (no shell expansion, throws on failure) the exec helper already assumes. Also retries `dotnet tool restore` once on failure: dotnet/sdk#53783 causes cold-cache restores of 2+ RID-specific tool packages (nupkg-validator and assembly-differ, both native-AOT now) to misattribute one package's DotnetToolSettings.xml to another. A retry always succeeds since the resolver cache is warm afterward. Co-authored-by: Cursor --- build/scripts/Targets.fs | 11 ++++++++++- build/scripts/scripts.fsproj | 2 +- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/build/scripts/Targets.fs b/build/scripts/Targets.fs index dfeb831..26ab01d 100644 --- a/build/scripts/Targets.fs +++ b/build/scripts/Targets.fs @@ -13,7 +13,16 @@ open ProcNet let exec binary args = Proc.Exec (binary, args |> List.toArray) -let private restoreTools = lazy(exec "dotnet" ["tool"; "restore"]) +/// dotnet/sdk#53783: on a cold tool-resolver cache (every fresh CI runner, every fresh container), +/// restoring 2+ RID-specific tool packages in one manifest can misattribute one package's +/// DotnetToolSettings.xml to another, failing with "The command ... is not contained in the +/// package ...". The cache is warm after the first attempt, so a bare retry always succeeds - +/// see https://github.com/dotnet/sdk/issues/53783. +let private restoreTools = + lazy( + try exec "dotnet" ["tool"; "restore"] + with _ -> exec "dotnet" ["tool"; "restore"] + ) let private currentVersion = lazy( restoreTools.Value |> ignore diff --git a/build/scripts/scripts.fsproj b/build/scripts/scripts.fsproj index 4136066..133d06c 100644 --- a/build/scripts/scripts.fsproj +++ b/build/scripts/scripts.fsproj @@ -8,7 +8,7 @@ - + From c6704f9a32f9a2d2599294578c625d934e447487 Mon Sep 17 00:00:00 2001 From: Martijn Laarman Date: Thu, 3 Sep 2026 10:44:04 +0200 Subject: [PATCH 2/2] Fix generateApiChanges diffing the empty root package instead of .any The plain "release-notes" 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. Diffing against it found 0 assemblies and failed the PR's own "Inspect public API changes" CI step: https://github.com/nullean/release-notes/actions/runs/33674817669/job/100397363448 The portable, signed managed build lives in "release-notes.any" instead; point previous-nuget at that. Verified locally against the real 0.11.0 package. Co-authored-by: Cursor --- build/scripts/Targets.fs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/build/scripts/Targets.fs b/build/scripts/Targets.fs index 26ab01d..5c0f447 100644 --- a/build/scripts/Targets.fs +++ b/build/scripts/Targets.fs @@ -109,7 +109,11 @@ let private generateApiChanges (arguments:ParseResults) = let args = [ "assembly-differ" - (sprintf "previous-nuget|%s|%s|net10.0" Paths.ToolName currentVersion); + // The plain "release-notes" package id is just a DotnetToolSettings.xml v2 shim pointing + // at per-RID sub-packages (see generatePackages above) - it ships no managed assembly of + // its own, so NuGetAssemblyProvider would find 0 assemblies there. The portable, signed + // managed build lives in "release-notes.any" instead. + (sprintf "previous-nuget|%s.any|%s|net10.0" Paths.ToolName currentVersion); (sprintf "directory|src/%s/bin/Release/net10.0" Paths.ToolName); "--target"; "release-notes"; "-f"; "github-comment"; "--output"; output ]