-
Notifications
You must be signed in to change notification settings - Fork 149
RFC for multi test run finalization #235
RFC for multi test run finalization #235
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Gets a current processor index. | ||
/// </summary> | ||
[DataMember] | ||
public long CurrentProcessorIndex { get; private set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are processors run linearly, even if the processor is associative?
or would it be possible for multiple processors to run simultaneously?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our code coverage report merger is merging files and removing not needed reports as DevOps is searching for all files with .coverage extension. Because of that we shouldn't run anything in parallel for same uris.
But in case we have two processors which are working on disjoint sets of Uris we can easily use them simultaneously
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just wondering if a single long will suffice, if we'd ever allow to run merges simultaneously, if that's not the case then having a single long is ok
namespace Microsoft.VisualStudio.TestPlatform.ObjectModel.Client | ||
{ | ||
[DataContract] | ||
public class MultiTestRunFinalizationProgressEventArgs : EventArgs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we have a progress for the set of attachments already processed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently we pass IProgress progressReporter to attachment processor. Every time reporter is used we propagate MultiTestRunFinalizationProgressEventArgs. When attachment processor is working we can't say which attachments are already done. We have separated callback to provide already processed attachments
/// Gets or sets whether Metrics should be collected or not. | ||
/// </summary> | ||
[DataMember] | ||
public bool CollectMetrics { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be sent on each finalization request?
or perhaps there's a better place where we can configure TP settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not expect sending a lot of finalization requests. Currently tests execution is also sending it in every request.
No description provided.