Skip to content

Speed up CI with NuGet cache + solution-wide build#317

Merged
erikdarlingdata merged 1 commit intodevfrom
chore/ci-cache-and-solution-build
May 9, 2026
Merged

Speed up CI with NuGet cache + solution-wide build#317
erikdarlingdata merged 1 commit intodevfrom
chore/ci-cache-and-solution-build

Conversation

@erikdarlingdata
Copy link
Copy Markdown
Owner

Summary

Two changes to .github/workflows/ci.yml:

  1. NuGet cache via setup-dotnet: cache: true with cache-dependency-path: '**/*.csproj' persists ~/.nuget/packages across runs. Cold restore (~90s on windows-latest) becomes a tar extract on cache hit. Cache invalidates whenever any .csproj changes.

  2. Solution-wide build: replaced five sequential dotnet restore + five sequential dotnet build invocations with one each against PlanViewer.sln. MSBuild builds the dependency graph in parallel internally, and we save four MSBuild startup cycles.

PlanViewer.Ssms and PlanViewer.Ssms.Installer are intentionally excluded from PlanViewer.sln, so they remain out of CI as before.

Expected impact

PS CI was ~7 min cold. Estimate after merge:

  • First run on this branch: similar time (~7 min — populates the cache).
  • Subsequent runs: ~3-4 min (cache hit eliminates the restore step entirely; solution build saves ~30-60s of MSBuild startup overhead).

Test plan

  • First run after merge — confirm CI passes (cache populates here)
  • Open a follow-up PR (or push a small commit) — confirm restore step shows cache hit and total runtime drops
  • Confirm the build still produces correct artifacts (no projects silently skipped from sln)

Followups

@erikdarlingdata previously called out path filters and ubuntu-latest migration as further wins. Both are out of scope here — this PR is the low-risk pair.

🤖 Generated with Claude Code

- setup-dotnet@v5 with cache: true persists ~/.nuget/packages between
  runs, keyed on **/*.csproj. Cold restore (~90s) becomes a tar
  extract on cache hit.
- Replace five sequential dotnet restore + five sequential
  dotnet build invocations with one each against PlanViewer.sln.
  MSBuild builds the dependency graph in parallel internally, and
  we save four MSBuild startup cycles.
- Tests still build via the solution build, then run with --no-build.

PlanViewer.Ssms and PlanViewer.Ssms.Installer are intentionally not in
PlanViewer.sln, so they remain excluded from CI as before.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@erikdarlingdata erikdarlingdata merged commit 6a4338d into dev May 9, 2026
2 checks passed
@erikdarlingdata erikdarlingdata deleted the chore/ci-cache-and-solution-build branch May 9, 2026 16:30
erikdarlingdata added a commit that referenced this pull request May 9, 2026
Linux runners are ~2x faster than windows-latest on GitHub-hosted.
None of the projects in PlanViewer.sln are Windows-only:
- PlanViewer.Core, .App, .Cli are net8.0 cross-platform
- PlanViewer.Web is Blazor WASM, builds on Linux with wasm-tools
- PlanViewer.Core.Tests is xunit on net8.0
- PlanViewer.App already references SkiaSharp.NativeAssets.Linux

PlanViewer.Ssms (legacy net472 + VSSDK) is not in the solution and
is not built in CI; it stays Windows-only via its own workflow if
one exists.

If anything fails on Linux that's not flaggable as a small fix,
revert this PR and we keep the cache + solution-build wins from #317.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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