Write the release notes in one pass, not from every PR - #3026
Merged
Conversation
The header said every PR that changes something a user can notice edits this file in the same commit. That makes every PR append to the same list under the same anchor, so they conflict with each other even when the entries are unrelated. Each conflict costs a merge commit and a full CI run, and the same text gets reviewed again in every PR that touched the file. The goal was one set of notes to read and approve. One pass before a release keeps that, and the pass before the next prerelease only adds what merged since the last one, so it stays a small diff. The material comes from the merged PR descriptions, not from raw commit messages. 🤖
nohwnd
added a commit
that referenced
this pull request
Sep 5, 2026
See #3026. This PR appending to the shared list is what causes the conflicts. 🤖
nohwnd
added a commit
that referenced
this pull request
Sep 5, 2026
* Apply Pester.BeforeContainer.ps1 when only discovery runs Run.SkipRun returns the discovered tree without executing anything, which is the path the VS Code Test Explorer uses to populate. It goes through Discover-Test, a batch discovery over all containers, and that function never took the BeforeContainer map, so it called Invoke-ContainerDiscovery without -BeforeContainerFile. A file whose discovery depends on the setup discovered fine in a normal run and came back empty when only discovery was requested. Discover-Test now takes the same map the interleaved discover -> run path gets, and resolves it per container, because which files apply depends on where the container is after #2993. Find-Test forwards it too. The per container lookup was written inline in Invoke-Test and is now a function that both paths call, so they cannot drift apart again. That also removes the case-insensitive variable name trap the inline version needed a comment to explain. Fix #3008 🤖 * Drop the release note entry, notes are written in one pass now See #3026. This PR appending to the shared list is what causes the conflicts. 🤖
nohwnd
added a commit
that referenced
this pull request
Sep 5, 2026
…3028) * Apply Pester.BeforeContainer.ps1 when only discovery runs Run.SkipRun returns the discovered tree without executing anything, which is the path the VS Code Test Explorer uses to populate. It goes through Discover-Test, a batch discovery over all containers, and that function never took the BeforeContainer map, so it called Invoke-ContainerDiscovery without -BeforeContainerFile. A file whose discovery depends on the setup discovered fine in a normal run and came back empty when only discovery was requested. Discover-Test now takes the same map the interleaved discover -> run path gets, and resolves it per container, because which files apply depends on where the container is after #2993. Find-Test forwards it too. The per container lookup was written inline in Invoke-Test and is now a function that both paths call, so they cannot drift apart again. That also removes the case-insensitive variable name trap the inline version needed a comment to explain. Fix #3008 🤖 * Drop the release note entry, notes are written in one pass now See #3026. This PR appending to the shared list is what causes the conflicts. 🤖 * Report which Pester.BeforeContainer.ps1 files applied to a container A container's setup comes from every Pester.BeforeContainer.ps1 between Run.RepoRoot and the test file's own folder, and nothing in the result said which ones were used. That makes "where did this function come from" unanswerable from the outside: opening tests/unit/Foo.Tests.ps1 shows no BeforeAll and gives no sign that two folder setups ran before it. Reading the directory tree is not enough either, because #pester:no-inherit can cut the chain short. The applied files are on the container now, outermost first, matching the order they ran in. On the container rather than the block, because it is a property of the file being run, and post-processors already walk containers. Fix #3007
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.
The header of
docs/NEXT-RELEASE.mdsaid:That makes every PR append to the same list under the same anchor, so they conflict with each other even when the entries have nothing to do with one another. #3023 already hit it once against #3021, and would hit it again against #3025. Each conflict costs a merge commit and a full CI run on an 8 leg matrix, and the same note text gets reviewed again in every PR that happened to touch the file.
The goal was one set of notes to read and approve. One pass before a release keeps that. The pass before the next prerelease only adds what merged since the last one, so it stays a small diff, and the material comes from the merged PR descriptions rather than raw commit messages.
No content change, only the instruction.
🤖