Transform build log from command line runner

Is there a way to preprocess the build log produced from the standard output of a process launched with the command line runner in order to output meaningful and colored messages like the built-in runners do?

10 comments
Comment actions Permalink

Simone,

For standard runners (incl. Command Line) there is no a universal way to transform the messages.
Currently you will need to write own runner that will handle messages it receives.

Feel free to file a feature request on that.

0
Comment actions Permalink

Ok Yegor. Say that I have to run msbuild from the command line and cannot rely on the TC runner, if I implemented my own custom runner on top of msbuild, which would be easy, would there be a way to reuse the logic you used to parse the output produced by msbuild to figure out where there are errors and thus paint them red, for example? The aim is to produce a more meaningful build log.

0
Comment actions Permalink

Simone,

It seems it is possible to write own TeamCity runner that will add own listener to MSBuild that in turn can deligate messages processing to standard TeamCity listener.
However .Net TeamCity listener is not part of open API so can be changed at any point without notice.

BTW, can you describe what type of mesasges do you want to custom process? Is this something specific to your setup or can be of general value? Are there some examples?

0
Comment actions Permalink

It seems it is possible to write own TeamCity runner that will add own listener to MSBuild that in turn can deligate messages processing to standard TeamCity listener.

However .Net TeamCity listener is not part of open API so can be changed at any point without notice.

That's about what I wanted to know

BTW, can you describe what type of mesasges do you want to custom process? Is this something specific to your setup or can be of general value? Are there some examples?

What I'd need to do is of general value and is to provide a colored build log even when I run MSBuild from the command line instead of using the built-in runner, so that - for example - errors appear in red just like the integrated runner does instead of having to fiddle through the 'All Messages' build log.

0
Comment actions Permalink

TeamCity's MSBuild logger could be attached to msbuild process that was started from commandline.
Path to logger assembly is set to the system property: 'system.teamcity.dotnet.nunitlauncher.msbuild.task'
So the following commandline argument would be:

/logger:%system.teamcity.dotnet.nunitlauncher.msbuild.task%,JetBrains.BuildServer.MSBuildLoggers.MSBuildLogger

TeamCity will replace the reference with exact path to MSBuild logger containing DLL.
In MSBuild script this reference would look $(teamcity_dotnet_nunitlauncher_msbuild_task)

If you need to customize logging, the idea is to create your own msbuild logger that delegates to TeamCity logger.

0
Comment actions Permalink

Hi Eugene, thank you very much for the reply, exactly what I needed. Are those properties documented? And are there anymore of them that might be useful like the one you mentioned?

0
Comment actions Permalink

Listener class name is not documented and may change. It is also not documented that path to listener class is in the mentioned property.

0
Comment actions Permalink

Thanks Eugene, I will take it as-is then.

0
Comment actions Permalink

Could you provide more information about how a logger would delegate to the TeamCity logger? Should the custom logger attempt to create an instance of the TeamCity logger (e.g. via Activator.CreateInstanceFrom(assembly, class);)? Should it be possible to attach multiple loggers by specifying the "/logger:..." parameter more than once?

0
Comment actions Permalink

This is all up to msbuild. MSbuild support only one logger. The idea behind was to implement a logger is able to create an instance of TeamCity logger and that will delegate all events to created TeamCity logger instance.

0

Please sign in to leave a comment.