Invalidate per-project restore skip when paket.lock content changes

[randrag]

This is to fix #4333 — Step 2a's skip in Paket.Restore.targets previously only watched paket.references, so transitive changes in paket.lock left the per-project paket.props stale. The fix adds a paket.lock content-hash check (Step 2 a-bis) and a one-line write of that hash after each successful per-project restore (Step 3 a-bis), plus a fall-through that fires once on first encounter for legacy checkouts that pre-date the cache file.

Test in RestoreSpecs.fs follows the existing #2684 / #3527 patterns: full restore, mutate paket.lock content, assert that the next dotnet restore requests a per-project restore (via PAKET_ERROR_ON_MSBUILD_EXEC=true).

[nicholi]

Would really like to see this reviewed and commented on.

I think it possibly resolves an issue I've had forever. My only solution was just manually purging bin/obj dirs between any paket.lock changes (or even more mundane things like switching branches with different paket.locks).

[Copilot]

Pull request overview

This PR fixes Paket’s MSBuild “skip per-project restore” optimization so it also invalidates when paket.lock content changes (not just when paket.references changes). This prevents stale per-project paket.props / *.paket.resolved under redirected BaseIntermediateOutputPath, which can otherwise cause NuGet to keep resolving old transitive versions indefinitely.

Changes:

• Extend Paket.Restore.targets Step 2 with a per-project cached SHA256 of paket.lock to force per-project restore when lock content changes (and a one-time fallback when the cache file is missing).
• Stamp the per-project lock hash cache after successful per-project restore.
• Add a new integration scenario plus an integration test asserting that a lock-content change triggers per-project restore (via PAKET_ERROR_ON_MSBUILD_EXEC=true).

Show a summary per file

File	Description
src/Paket.Core/embedded/Paket.Restore.targets	Adds per-project paket.lock hash invalidation and writes the hash cache after per-project restore.
integrationtests/Paket.IntegrationTests/RestoreSpecs.fs	Adds a regression test for lock-content invalidation of the per-project restore skip.
integrationtests/scenarios/i4333-lock-content-invalidates-project-props/before/Directory.Build.props	New scenario that redirects BaseIntermediateOutputPath and disables global restore (to reproduce the original bug).
integrationtests/scenarios/i4333-lock-content-invalidates-project-props/before/paket.dependencies	New scenario dependencies file for the repro project.
integrationtests/scenarios/i4333-lock-content-invalidates-project-props/before/paket.lock	New scenario lockfile used to establish and then mutate lock content.
integrationtests/scenarios/i4333-lock-content-invalidates-project-props/before/project/paket.references	New scenario references file that remains unchanged while the lock is mutated.
integrationtests/scenarios/i4333-lock-content-invalidates-project-props/before/project/project.fsproj	New SDK-style repro project importing Paket.Restore.targets.
integrationtests/scenarios/i4333-lock-content-invalidates-project-props/before/project/Program.fs	Minimal program for the new repro project.

Review details

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 7/8 changed files
• Comments generated: 1
• Review effort level: Lite

[dsyme]

/repo-assist Check if the test added is actually running as part of the CI or is it in the integration tests we haven't fully enabled yet

[github-actions]

✓ Repo Assist completed successfully, see workflow run.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

[github-actions]

🤖 This is an automated response from Repo Assist.

Checked how the new test (#4333 paket.lock content change invalidates per-project restore skip in RestoreSpecs.fs) is wired up, and it is included in the required CI run, not just the integration-test suites — here's the trail:

1. Included in the project: RestoreSpecs.fs is compiled into Paket.IntegrationTests.fsproj (<Compile Include="RestoreSpecs.fs" />), and the test has no [<Category("Flaky")>] or other category attribute, so it's a normal, always-run integration test.
2. CI job that runs it: .github/workflows/ci.yml's linux job has a build matrix entry (skip_env: SkipIntegrationTests=true is only set for that entry) plus a flaky entry (PAKET_TESTSUITE_FLAKYTESTS=true) — there is no longer a dedicated net/netcore matrix entry (those were removed in commit 7088d11, "Exclude rotted integration suites from Actions CI"). That means on Linux, integration tests including this one only run via the fallback All → BuildPackage pipeline in build.fsx, which chains RunIntegrationTestsNet and RunIntegrationTestsNetCore unless SkipIntegrationTests* build params are set. Since the current Linux matrix has no entry that runs integration tests without skipping them, this test does not currently execute on the Linux CI job — only the windows job (.\build.cmd BuildPackage, no skip flags) runs the full RunIntegrationTestsNet/RunIntegrationTestsNetCore targets, which include this test (filtered only by TestCategory!=Flaky).
3. So in practice: this test does run in CI, but only on the Windows job, not on Linux (where integration tests are currently skipped entirely per the build matrix entry). It is not "not fully enabled" — it will execute and gate windows CI — but Linux coverage for it is currently absent because of the CI trim done in 7088d11.

No code changes proposed here since this reflects an existing, intentional-looking trim of Linux integration-test coverage (not something introduced by this PR). Flagging for the maintainer's awareness in case Linux integration coverage should be restored.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
_{Comment /repo-assist to run again}

_{Add this agentic workflow to your repo}

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@ae8d551f07c7ed7619f8c58c7bb4c3ac89395d38