Normalize the source paths in the embedded PDB on build servers - #3025
Merged
Conversation
DebugType=embedded is worth keeping, it is what puts file and line numbers into stack traces from Pester's own C# code. But the paths in those traces are the build machine's absolute paths and they ship that way. 6.1.0 carries D:\a\1\s\src\csharp\Pester\..., which is the Azure agent's working directory. ContinuousIntegrationBuild turns on DeterministicSourcePaths, and the .NET 8 SDK has SourceLink built in, so no package is needed. Paths become /_/src/csharp/Pester/... and the line numbers are unchanged. Set only on a build server. A local build keeps the real path so the trace points at a file the editor can open. The condition covers TF_BUILD and GITHUB_ACTIONS, because CI is GitHub Actions but releasing still runs on Azure DevOps, and normalizing only CI would leave the released binaries carrying the path, which is the case this is about. It also makes the build reproducible. The same source in two folders produced two different Pester.dll files before, the only difference being the embedded path. Fix #3009 🤖
nohwnd
enabled auto-merge (squash)
September 5, 2026 08:24
This was referenced Sep 5, 2026
nohwnd
added a commit
that referenced
this pull request
Sep 5, 2026
* Write the 6.2.0-alpha2 release notes pass Covers the four user visible pull requests merged since alpha1. #3025 and #3021 were already in the file. Should-BeFasterThan and Should-BeSlowerThan rejecting what they cannot measure is a behavior change, not a fix. A test that passed on a string or an int was not asserting anything and it fails now. 🤖 * Bump the manifest to alpha2 The notes heading moved to 6.2.0-alpha2 but src/Pester.psd1 still said alpha1, so the built module would have published as 6.2.0-alpha1 again. Prerelease and the ReleaseNotes link follow the heading. ModuleVersion and RequiredAssemblyVersion stay at 6.2.0, only the prerelease label changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix #3009
DebugType=embeddedis worth keeping, it is what puts file and line numbers into stack traces from Pester's own C# code. But the paths in those traces are the build machine's absolute paths and they ship that way.What 6.1.0 shipped to everyone:
D:\a\1\sis the Azure agent's working directory.ContinuousIntegrationBuildturns onDeterministicSourcePaths, and the .NET 8 SDK has SourceLink built in, so there is no package to add. One property.Only on a build server
Locally the real path is what you want, so the trace points at a file the editor can open. Verified all three:
The condition covers both
TF_BUILDandGITHUB_ACTIONSon purpose. CI is GitHub Actions since #2905, but releasing still runs on Azure DevOps for the signing service connection, so gating onGITHUB_ACTIONSalone would normalize CI builds and leave the released binaries carrying the path, which is the case this issue is about.It also makes the build reproducible
The same source in two folders produced two different
Pester.dllfiles, the only difference being the embedded path. I hit this by accident while proving an unrelated change did not affect the artifact. With the property set, two directories produce the same bytes:Verification
Builds clean on
net8.0andnet462, 0 warnings, 0 errors.tst/Pester.Tests.ps1green. Line numbers in traces are unchanged, only the path root moves.No test for this one. Asserting on the PDB contents would only pass on a build server, and the property is inert locally, so the test would be skipped exactly where it could regress. LMK if you want it anyway, it would have to be a CI-only check.
🤖