GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||
GeezerVison is showing github.com — Parallelize the windows CI to enable us to run all tests all the time by TravisEz13 · Pull Request #8868 · PowerShell/PowerShell Conversation
|
By projects? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Ilya (@iSazonov) I don't want to design the solution right now. By project, would be a possibility, but optimally, we should try to find a way that makes sense and divides the time close to evenly. I think our first goal would be to do a similar refactoring of the non-windows CI system. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Travis Plunk (@TravisEz13) Why we do not select Build in a separate job to use the result for the rest jobs? Also perhaps we could use strategy-matrix to unify process. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
Ilya (@iSazonov) Review the change. We do the build as a separate job and use the results (artifacts) for the rest of the jobs. Matrix is less flexible that designing the pipeline yourself. We would not be able to do the build is a separate job and use the artifacts for the rest of the jobs. Using templates gets you all the advantages of a matrix (not having to restate the job multiple times, only declare how many times you want to run it), with the added ability to depend on previous jobs. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| $SkipFailing | ||
| ) | ||
| $env:CoreOutput = Split-Path -Parent (Get-PSOutput -Options (Get-PSOptions)) | ||
| if(!(Test-Path "$env:CoreOutput\pwsh.exe")) |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Can we change this to work on Linux and macOS
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
In the PR xUnit tests run only on Windows. Previously we run the tests on Unix-s too.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
This PR doesn't change Linux or macOS. I'll deal with this issue when refactoring macOS and Linux
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Travis Plunk (@TravisEz13) Thanks for clarify! I see now how this works. For reference Setting up parallel jobs, Slicing the test suite |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
…PowerShell#8868) Split Windows CI into the following Jobs 1. Combine Build and xUnit, which published build artifact 1. Elevated CI tests 1. Unelevated CI test 1. Elevated everything else tests 1. Unelevated everything else tests 1. Package build and test 1. Verify xUnit result ## PR Context Before this test: - A CI run would take ~14 minutes - A Feature run would take ~30 minutes After this change, it always runs all tests and takes ~20 minutes. Job `Unelevated everything else tests` is the long poll, taking ~4 minutes longer than the next shortest job. We should be able to get this back down to ~15 if we split that test job somehow.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.