fix: Revise dependency caching

[rubo]

Changes

Replaced the manual buggy NuGet package caching with one of actions/setup-dotnet. It's based on the lock file of Nethermind.Runner; hence, it doesn't cover the packages referenced by test projects. Nevertheless, the vast majority of packages are cached, greatly reducing the burden.

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: CI caching optimization

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Notes on testing

Requires manual testing

[claude]

Claude finished @rubo's task in 1m 55s —— View job

---

Review

• Gather context and read changed files
• Read workflow rules
• Review workflow changes
• Post findings

---

Scope: 3 workflow files, 6 actions/setup-dotnet@v5 steps — each gains cache: true and cache-dependency-path: src/Nethermind/**/packages.lock.json.

No critical, high, or medium findings. The change is correct and well-scoped.

---

Findings

Low — Cache miss on test-only package changes (acknowledged in PR description)

Only src/Nethermind/Nethermind.Runner/packages.lock.json exists in the repo. Test projects don't generate lock files (RestorePackagesWithLockFile is not set in their csproj), so if a test-only NuGet dependency is bumped without touching Runner's transitive closure, the cache key won't change. In practice most test packages are already pulled in transitively by Runner, so real-world impact is minimal. The PR description explicitly acknowledges this trade-off.

Info — codecov-upload job left uncached (intentional)

nethermind-tests.yml line 307 has a bare setup-dotnet@v5 without caching. That job only runs dotnet tool install --global dotnet-coverage — no dotnet restore — so there are no NuGet package artifacts to cache. The omission is correct.

Info — Glob pattern is more general than the PR description states

src/Nethermind/**/packages.lock.json would match any lock file added in future. Currently it resolves to exactly one file (Nethermind.Runner/packages.lock.json), consistent with the description. The glob is actually more future-proof than the description implies — new lock files will be automatically incorporated.

---

Overall: straightforward, low-risk CI improvement. ✅

[claude]

Claude finished @rubo's task in 43s —— View job

---

Review

• Read workflow rules and changed files
• Analyze caching configuration
• Post findings

---

Scope: 3 workflow files, 6 actions/setup-dotnet@v5 steps — each gains cache: true and cache-dependency-path: src/Nethermind/**/packages.lock.json.

No critical, high, or medium findings. The change is correct and well-scoped.

---

Findings

Low — Cache miss on test-only package changes (acknowledged in PR description)

Only src/Nethermind/Nethermind.Runner/packages.lock.json exists in the repo. Test projects don't generate lock files (RestorePackagesWithLockFile is not set in their .csproj), so if a test-only NuGet dependency is bumped without touching Runner's transitive closure, the cache key won't change. In practice most test packages are already pulled in transitively by Runner, so real-world impact is minimal. The PR description explicitly acknowledges this trade-off.

Info — codecov-upload job left uncached (intentional)

nethermind-tests.yml line 307 has a bare setup-dotnet@v5 without caching. That job only runs dotnet tool install --global dotnet-coverage — no dotnet restore — so there are no NuGet package artifacts to cache. The omission is correct.

Info — Glob pattern is more general than the PR description states

src/Nethermind/**/packages.lock.json would match any lock file added in future. Currently it resolves to exactly one file (Nethermind.Runner/packages.lock.json), consistent with the description. The glob is actually more future-proof than the description implies — new lock files will be automatically incorporated.

---

Overall: straightforward, low-risk CI improvement. ✅