How to group 'MSTest report watcher' messages?
The Problem
I have hit interesting problem of impossible grouping of the 'MSTest report watcher' messages.
Description
MSTest report watchers are invoked via service message(s). E.g. ##teamcity[importData type='mstest' path='$path']" inside separate build task. Each processed service message at TC immediately runs watcher which incurs logging information about it. These messages are propagated at same level as other build tasks.
Similar applies when watcher reports successful operation.
I tried some attempts with blockOpened/blockClosed with flowId or flowStarted/flowFinished with parentality and also teamcity.internal.serviceMessages.suppress build parameter with various varitions of importDataStarted,importDataFinished. All to no avail, messages are still printed and still printed “out of order”.
TeamCity Enterprise 2023.05.4 (build 129421)
Legend
- Brown ones are buid tasks, black and gray unimportant imformation, orange interesting information.
- It can be seen how MSTest report watcher is sorted onto build task level and how it prints “where it needs and when it needs”.
Is there clear solution to grouping watcher messages under build task in which were invoked?
Please sign in to leave a comment.
Hi,
If I understand correctly, this behavior is expected.
According to the documentation, XML Report Processing completes the parsing of files only at the end of the build. As you mentioned, this phase is indicated in orange in the UI. For more details, please refer to the official documentation: Importing XML Reports.
After the `importData` message is received, TeamCity agent starts to monitor the specified paths on the disk and imports matching report files in the background as soon as the files appear on disk.
The parsing only occurs within the build step in which the messages were received. On the step finish, the agent ensures all the present reports are processed before beginning the next step. This behavior is different from that of the XML Report Processing build feature, which completes files parsing only at the end of the build.
Ensure the report files are available after the generation process ends (the files are not deleted, nor overwritten by the build script)
By the way, TeamCity 2023.05.4 reached the end of the support stage. I strongly recommend upgrading due to patched security issues, let alone other fixes and improvements.
Best Regards,
Tom
Surely, it is. But I am interested in more drive on this. fmpov,
then changes to “The parsing only occurs within the build task in which the messages were received.”. So, in the end xml processing report messages do not intermixes with parallely ongoing build task. Imagine situation when you have dozens of test assemblies. You would then struggle to find your build tasks among xml processing messages. Which more over are in fact useless, unless it reports failure.
Some logging level for xml processing would be enough.
Hi,
> So, in the end xml processing report messages do not intermixes with parallely ongoing build task.
Apologies for the confusion. Can you please clarify more about it?
As I mentioned, XML Report Processing only parses the files after the build finishes. You can refer to the attached screenshot — the parsed reports are clearly visible and easy to access.
> You would then struggle to find your build tasks among xml processing messages. Which more over are in fact useless, unless it reports failure.
TeamCity’s build log UI allows filtering and searching directly. It's easy to locate the specific information you need without being distracted by unrelated log messages
> As I mentioned, XML Report Processing only parses the files after the build finishes.
This true as long as XML Report processing is establishing using build feature, documented at https://www.jetbrains.com/help/teamcity/xml-report-processing.html.
But we do use service messages for this, so report processing is fired ∓ immediately, documented at https://www.jetbrains.com/help/teamcity/service-messages.html#Importing+XML+Reports. In a separate build task messages are passed to teamcity. On the picture of main post this is the grayed out one.
Immediate invocation, incurs immediate logging which logs racing with other logging events making log not clear for reading.
> TeamCity’s build log UI allows filtering and searching directly.
Surely, but often when one is inspecting log, don't know what is seeking for.
However, by the ways of ways I found solution to this problem — to use teamcity logger instead of trx logger.
Reference:
Beside avoiding lunching trx report parser and file watching per report file, teamcity logger/adapter is capable of grouping tests by test assembly which is not true fro XML processing feature.