Make Run.ParallelThrottleLimit = 1 run sequentially in the current session - #2973
Closed
nohwnd wants to merge 1 commit into
Closed
Make Run.ParallelThrottleLimit = 1 run sequentially in the current session#2973nohwnd wants to merge 1 commit into
nohwnd wants to merge 1 commit into
Conversation
…ssion Throttling to 1 already meant one file at a time, but the file still ran in a worker runspace. That is the worst of both: no speedup, and no debugging, because breakpoints are set per runspace so a breakpoint set in the session that called Invoke-Pester never hits inside a worker. Now 1 falls back to the normal sequential path, next to the other fallbacks (Windows PowerShell 5.1, ScriptBlock containers, SkipRemainingOnFailure = 'Run'). So the same configuration can be used to step through a test that only misbehaves under Run.Parallel, by turning the throttle down to 1, instead of remembering a second option to flip. 🤖
Member
Author
|
Not the direction we want to take. Enabling Run.Parallel means the files run in runspaces, throttling to 1 just means one runspace at a time. If you don't want parallel, don't enable it. 🤖 |
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
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.
Comes out of #2971, where @DarkLite1 described the pattern he uses in his own code: one function that runs a scriptblock over items, and when you set
-ThrottleLimit 1it drops to a plainforeachon the main thread so you can step through it. Same knob for concurrency and for debugging.Run.ParallelThrottleLimit = 1did not do that. It ran one file at a time, but still inside a worker runspace, so you got no speedup and no debugging: breakpoints are per runspace, a breakpoint set in the session that callsInvoke-Pesternever hits inside a worker.Now 1 falls back to the normal sequential path, next to the fallbacks we already have (Windows PowerShell 5.1,
ScriptBlockcontainers,Run.SkipRemainingOnFailure = 'Run'). The banner also stops saying "in parallel", because the run is not parallel.No new configuration option, and no new switch on
Invoke-Pester. Turn the throttle you already have down to 1 and you can debug the file.Before:
After:
Tests added in
tst/Pester.RSpec.Parallel.ts.ps1: the breakpoint hits, the banner does not claim parallel, and the counts match a parallel run.test.ps1 -File tst/Pester.RSpec.Parallel.ts.ps1passes 25/25,PesterConfiguration.Tests.ps1andHelp.Tests.ps1pass, andInvoke-ScriptAnalyzeronsrc/Main.ps1reports the same 9 pre-existing findings asmain.Open question: someone might want 1 file at a time but still isolated in a runspace, to tell an isolation problem apart from a concurrency problem. That is what this takes away. I think the debugging case is worth more, LMK if you disagree.
🤖