Port parallel per assembly test running from ServiceControl - #16
Conversation
|
|
||
| $testSdkNodes = Select-Xml -Path $project -XPath "/Project/ItemGroup/PackageReference[@Include='Microsoft.NET.Test.Sdk']" | ||
| if ($hasExplicitProjects) { | ||
| $projectPaths = $explicitProjectsRaw -Split "`n" | ForEach-Object { $_.Trim() } | Where-Object { $_ } |
There was a problem hiding this comment.
Out of curiosity, why did you choose newline instead of space? I'm asking because when using command line arguments on CLIs, they are usually space-separated, comma-separated, or a repeated argument, but a new line sounds error-prone across operating systems
There was a problem hiding this comment.
It was a faithful porting of the script in ServiceControl
It should probably be ; like the platforms list
| inputs: | ||
| reset-script: | ||
| description: 'pwsh expression to be run between test runs to reset infrastructure, if required' | ||
| description: 'pwsh expression to be run between test runs to reset infrastructure, if required. Only used when max-parallel is 1; ignored (with a warning) when max-parallel > 1.' |
| $pending = [Collections.Generic.Queue[object]]::new($runs) | ||
| $active = [Collections.Generic.List[object]]::new() | ||
|
|
||
| while ($pending.Count -gt 0 -or $active.Count -gt 0) { |
There was a problem hiding this comment.
In the old RavenDB actions I used the foreach with the parallel option but I can't remember what the tradeoffs were.
https://devblogs.microsoft.com/powershell/powershell-foreach-object-parallel-feature/
There was a problem hiding this comment.
This seems much better than managing a custom loop and some of the drawbacks about how it handles output seem to be overblown as long as you write everything using pipelines.
I'll swap it over tomorrow.
2 participants
Follow up from: Particular/ServiceControl#5783 (comment)
This pull request introduces significant enhancements to the
run-testsGitHub Action, most notably adding support for running a subset of projects and enabling parallel execution of test runs. These changes improve flexibility and performance, especially for repositories with large or categorized test suites. Documentation and input parameters have been updated accordingly to reflect the new features and their usage.Enhancements to test execution:
projectsinput, allowing users to bypass auto-discovery and specify which test projects to run. This is particularly useful for test suites subdivided by category. (README.md,action.yml,run-tests.ps1) [1] [2] [3]max-parallelinput to enable concurrent execution of test assemblies (1–16 in parallel), with per-run output buffering and replay for readability. When parallel execution is enabled,reset-scriptis ignored and a warning is emitted. (README.md,action.yml,run-tests.ps1) [1] [2] [3]Environment and resource management:
PARTICULAR_RUN_TESTS_ACTION_PARALLEL_INDEXenvironment variable, allowing consumers to allocate unique resources (e.g., ports or temp directories) per run. (README.md,run-tests.ps1) [1] [2] [3]Documentation and input updates:
README.mdwith detailed usage instructions and examples for the newprojectsandmax-parallelfeatures, including guidance on parallel index usage and reset script behavior.projectsandmax-parallelinputs inaction.yml, and clarified the behavior ofreset-scriptin parallel mode. [1] [2]Internal refactoring:
run-tests.ps1to support both sequential (historic) and parallel execution modes, including logic for project selection, framework targeting, and process management. [1] [2] [3]These changes collectively make the action more powerful and adaptable to complex CI scenarios.