Update configure-unit-tests-by-using-a-dot-runsettings-file.md #4938
Conversation
|
@nohwnd : Thanks for your contribution! The author(s) have been notified to review your proposed change. |
|
@kendrahavens @AbhitejJohn for review |
| @@ -253,6 +253,7 @@ The **RunConfiguration** element can include the following elements: | |||
| |**TestAdaptersPaths**||One or more paths to the directory where the TestAdapters are located| | |||
| |**MaxCpuCount**|1|This setting controls the degree of parallel test execution when running unit tests using available cores on the machine. The test execution engine starts as a distinct process on each available core, and gives each core a container with tests to run. A container can be an assembly, DLL, or relevant artifact. The test container is the scheduling unit. In each container, the tests are run according to the test framework. If there are many containers, then as processes finish executing the tests in a container, they're given the next available container.<br /><br />MaxCpuCount can be:<br /><br />n, where 1 <= n <= number of cores: up to n processes are launched<br /><br />n, where n = any other value: the number of processes launched can be up to the number of available cores. For instance, set n=0 to let the platform automatically decide the optimal number of processes to launch based on the environment.| | |||
| |**TestSessionTimeout**||Allows users to terminate a test session when it exceeds a given timeout. Setting a timeout ensures that resources are well consumed and test sessions are constrained to a set time. The setting is available in **Visual Studio 2017 version 15.5** and later.| | |||
| |**DotnetHostPath**||Specify a custom path to dotnet host that is used to run the testhost. This is useful when you are building your own dotnet, for example when building the dotnet/runtime repository. Specifying this option will skip looking for testhost.exe, and will always use the testhost.dll. | |||
There was a problem hiding this comment.
@nohwnd : I wonder if we want to document this. Would we need to support additional unplanned workflows with this? Would other teams apart from the dotnet team for instance need this...
There was a problem hiding this comment.
I don't know. Probably not. This is mainly aimed to the dotnet team because they are building their own dotnet. I already expressed my concerns about this being yet another config option in already complex thing. So I will happily keep this undocumented.
|
Merging per @kendrahavens approval |
|
I will revert this in a new PR, per previous comments. |
|
@Mikejo5000 Was @AbhitejJohn saying hold off? I apologize if I misunderstood. |
|
@ktoliver Yes, no problem. Would you mind reverting it? I got auto-closed on the public repo when I tried the "Revert" button, so I'd have to wait for the sync with the private repo. |
|
Let me check in with @tfosmark. We've been asked to not use the Revert button. Stay tuned... |
|
@Mikejo5000 The word is that PR reviewers aren't intended to revert a merge. So, submitting a new PR is the way to go, despite sync issues. |
|
@Mikejo5000 Updating via a PR directly in the private repo might be quicker. |
|
Thanks folks. Apologies for the confusion. We'd prefer this change be reverted. |
|
@AbhitejJohn Got it, no worries. Despite the existence of a Revert button in the GitHub UI, the process for reverting is to submit a new PR that contains the content you want to show up--that is, the pre-updated version. @Mikejo5000 I can do this in the private repo, if you'd like. An update from the private repo with the ~3 PM publish should override/replace the version in this PR. (That's my understanding, anyway.) |
|
Sure, that would be great. Thanks! |
|
@Mikejo5000 @AbhitejJohn The article from my revert PR is live: https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019. As long as the AM publish sync PR went through before my PR went live around 3:30 PM (I don't know the details of that schedule), the update should be successfully reverted. |
|
@ktoliver : That looks good. Thanks 👍 |
|
Yup, thx! |
Add DotnetHostPath runsetting docs.