Find the repository root from the session location, not the process working directory

[nohwnd]

Found while writing the 6.2.0-alpha1 notes: I wrote a repository with Pester.BeforeContainer.ps1 at three levels, ran it, and none of them applied. It took two runs to work out why.

Run.RepoRoot decides which setup files apply, and its default is found by walking up for a .git directory. The walk runs in C# from Directory.GetCurrentDirectory(), the process working directory, and Set-Location does not change that:

pwsh                     # process working directory is now ~
cd ~/p/myrepo
Invoke-Pester ./tests    # RepoRoot is still ~, no Pester.BeforeContainer.ps1 applies

The run is green, the setup silently did nothing, and there is no warning. It is pre-existing, Run.RepoRoot shipped in 6.1.0, but #2993 made the whole folder cascade depend on it so it is worth fixing before the alpha goes out.

Change

FindRepoRoot takes the directory to start from, and Invoke-Pester resolves RepoRoot from $ExecutionContext.SessionState.Path.CurrentFileSystemLocation before the run, next to where the shuffle seed is resolved. That is the same source Pester.Parallel.ps1 already uses for the working directory it hands to workers.

Only when the option was not set. An explicit Run.RepoRoot is the user's to decide and is left alone.

The parameterless overload stays as the value an unused configuration object shows, so [PesterConfiguration]::Default still reports a directory rather than nothing.

Verification

Three tests next to the existing cascade tests:

• the cascade applies after Set-Location with no RepoRoot set. It also asserts the process directory and the session location actually disagree, so it cannot pass by accident on a runner that happens to start in the right place
• an explicit Run.RepoRoot survives the run
• FindRepoRoot falls back to the directory it started from when there is no .git above it

The first one fails without the change (43/44) and passes with it (44/44). Full suite on PS 7.5 macOS: P phase clean, RSpec 2921 passed, 0 failed, 3 skipped.

about_PesterConfiguration.help.txt is regenerated by build.ps1 -Clean, so it is in the same commit.

Based on release-6.2.0-alpha1 (#3014) because it adds its entry to docs/NEXT-RELEASE.md, which that PR introduces. Retargets to main on its own once #3014 merges.

🤖

[nohwnd]

No checks run on this PR: ci.yml and code-analysis.yml only trigger for pull requests whose base is main, rel/* or dev/*, and this one is based on release-6.2.0-alpha1 so it matches none of them.

The branch contains both commits, so I dispatched the two workflows against it directly, which tests exactly the state that lands on main:

• CI: https://github.com/pester/Pester/actions/runs/33241651570
• Code analysis: https://github.com/pester/Pester/actions/runs/33241652879

Once #3014 merges this retargets to main on its own and gets normal PR checks.

Worth considering separately: adding a base pattern for stacked release branches to ci.yml, or naming them dev/* so they are covered by what is already there.

🤖