How to use flowId?

I try to separate the result of a parallel devenv build with TeamCity 6.5.1. It seemed to me that the flowId attribute would be a perfect solution for this task.

I tried to understand the behavior of the flowId attribute with service messages using the following command line build step:


echo ##teamcity[message text='Starting...']
echo ##teamcity[message flowId='1' text='1.1']
echo ##teamcity[message flowId='2' text='2.1']
echo ##teamcity[message flowId='1' text='1.2']
echo ##teamcity[message flowId='2' text='2.2']
echo ##teamcity[message text='Finished.']


The result in the tree view looks like this:

Starting...
Finished.

The messages with flowId are visible in all messages but not in the tree view.

I tried adding block messages, but without success regarding the separation of parallel messages which I would like to group by flowId.

What am I doing wrong?

3 comments
Comment actions Permalink

Sorry for delay. At the moment flowId attribute is mostly used for tests. With help of this TeamCity can calculate correct number of tests in the build. However, there is still an open question how to show parallel flows in build log. The problem you describing is a known issue of Tree View and we are working on a fix for it. Chances are you'll see better results in the one of TeamCity 7.0 EAP builds.

0
Comment actions Permalink

We're up to TeamCity 10.0.3 - are the chances of seeing something better - or at least documentation of what FlowID is for - any more likely now?

Currently, I have two parallel phases in my build: setting up all the simulators while building, and running the tests, and I have two mechanisms for both:

1. for the 'build while setting up simulators', I send all the output mixed up, with suitable markers to show which process is printing what, and have a monitoring thread that closes the output block and re-opens it when it's finished emitting a periodic task summary tree to show which tasks have completed, and which tasks are waiting for which other tasks. This is a simple tree, and shows progress usefully.

2. For the tests, I log each thread to a separate file, and copy the setup, testing, and teardown phases to the central log using a mutex, but this still periodically gets corrupted apparently due to flushing issues.

One thing that would be really good: some sort of explicit depth level in block open/close, where any blocks opened or closed within some particular block depth, would be auto-closed (or auto-opened) by blocks of explicit lesser depth: that way, I could put 'default' depth blocks in my test code, and have the wrapper code's depth='2' blocks account for but hide any nesting errors.

0
Comment actions Permalink

Hi, Tim, please let me first clarify how the flowId works.

Imagine a build which runs two tests in parallel and reports them as TeamCity service messages without any flowId:


 This will result in the following unexpected results: test2 will be treated as nested inside test1 and in fact ignored. The std-err will be mixed-up:

So the right approach here would be to use flowId:

Thanks to the flowId TeamCity will correctly distinguish between two parallel flows of messages:

Similar to OS threads flows can be started one from another which means that there appears a separate subtree in a build log tree. As to the blocks - inside such a subtree if a block is closed - all it's currently opened child blocks (having the same flowId) are also closed.

The issue here is that though thanks to flowId the failures are detected correctly - the Build log TeamCity tab still shows 2-D tree and the messages are shown in order of their appearance which may look weird (and yet please note that the block statuses and levels are shown correctly):

The issue is filed in our tracker as https://youtrack.jetbrains.com/issue/TW-46515 and we will appreciate any ideas on how to represent such a structure not forgetting about performance, possible huge log sizes and lots of flows.

0

Please sign in to leave a comment.