Skip to content

fix(ci): shut down MSBuild build-server before restore and build - #10

Open
KiarashMinoo wants to merge 1 commit into
mainfrom
fix/pack-solution-build-server-staleness
Open

fix(ci): shut down MSBuild build-server before restore and build#10
KiarashMinoo wants to merge 1 commit into
mainfrom
fix/pack-solution-build-server-staleness

Conversation

@KiarashMinoo

@KiarashMinoo KiarashMinoo commented Jul 28, 2026

Copy link
Copy Markdown
Owner

User description

Summary

  • pack-solution.ps1 runs Clean, Restore, and Build as three separate dotnet invocations, but the .NET SDK keeps a persistent MSBuild/VBCSCompiler server warm across them by default.
  • If Clean deletes files that a consumer's own Directory.Build.props-style targets manage (e.g. downloading shared config into a gitignored scratch folder on a BeforeTargets="Restore" hook), that warm server can serve the following Restore call a stale "nothing to restore" evaluation from before those targets had anything to fetch — silently skipping them and leaving Build to fail on missing package/property state that never actually gets (re)downloaded.
  • This showed up as a real CI failure in ThunderPropagator (BuildingBlocks/Ardalis/CaseConverter type-not-found cascade on ThunderPropagator.Application), and reproduces the exact same failure signature I confirmed and root-caused separately this session for the local dotnet restore/dotnet build-server staleness bug.
  • Adds dotnet build-server shutdown immediately before Restore and before Build, forcing a cold, disk-accurate evaluation each time. This is a no-op when the staleness bug isn't in play, so it's safe for every consumer of this script.

Caveat: I could not reproduce the exact CI failure locally on a single clean run — my working theory is that the staleness compounds across the workflow-level retry loop (an initial attempt hits an unrelated transient blip, but the warm server surviving into the retry then causes the real no-op-restore failure). The fix addresses the confirmed staleness bug class regardless, but isn't a 100%-proven root cause for this specific incident.

Test plan

  • Validated PowerShell syntax of the edited script
  • Confirmed main branch protection requires a PR (no direct push)
  • Re-run ThunderPropagator's CI to confirm the fix resolves the observed failure

PR Type

Bug fix


Description

  • Add build-server shutdown before restore

  • Add build-server shutdown before build

  • Prevent stale restore evaluation


Diagram Walkthrough

flowchart LR
  Clean["Clean"] --> SR["Shutdown before Restore"]
  SR --> Restore["Restore"]
  Restore --> SB["Shutdown before Build"]
  SB --> Build["Build"]
Loading

File Walkthrough

Relevant files
Bug fix
pack-solution.ps1
Add build-server shutdown before restore and build             

.github/scripts/pack-solution.ps1

  • Insert dotnet build-server shutdown before restore
  • Insert dotnet build-server shutdown before build
  • Add explanatory comments about server staleness
+15/-2   

Clean, Restore and Build in pack-solution.ps1 run as three separate dotnet
invocations, but the .NET SDK keeps a persistent MSBuild/VBCSCompiler server
warm across them by default. If a consumer's own Directory.Build.props-style
targets manage files outside NuGet's own restore inputs (e.g. downloading
shared config into a gitignored scratch folder on a BeforeTargets="Restore"
hook), that warm server can serve Restore a stale "nothing to restore"
evaluation from before those targets had anything to fetch, silently
skipping them and leaving Build to fail on missing package/property state
that never actually gets (re)downloaded -- especially once Clean has just
deleted whatever a prior attempt fetched. This compounds across the
workflow-level retry loop, since nothing previously reset the server
between attempts either.

Shutting the server down immediately before Restore and before Build forces
a cold, disk-accurate evaluation each time. No-op when the staleness bug
isn't in play.
@github-actions

Copy link
Copy Markdown

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🏅 Score: 95
🔒 No security concerns identified
⚡ No major issues detected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant