Remove the 1000 build problem limit set by team city

Hello Steve,

Can you please let me know the scenario where you need to raise more than 1000 build problems? These are meant to be build stoppers, and usually there are 1 to 3, maybe 5 problems reported before the build is finished as failed. 

Hello Fedor! Thanks for your answer. 

I might not be using this build failure condition correctly but my goal is to run a script that scans game assets in our game and let us know if there are issues with them. So the result of this command is more like a report. 
That's why i've added a build failure condition on a specific message in the log files because the script will always finish as success otherwise. 
In other words, the command has been successful at reporting a bunch of information on the different assets of the game. 
That's where the reported issues get higher than 1000.

So i suppose this is a standard limitation? I mean, this is not really an issue by itself...we can go through these logs and explore what we want. But it would have been nice having the real number of issues encountered instead of having this limited to 1000. 

Hello Steve,

Thank you for the details! While build problems are indeed not suited for this task, I can think of a couple other approaches. First of all, is the asset info that you are processing available only in the build log? Is it possible to run some sort of command line step to iterate through assets, or have build process pipe stdout to a file and parse it manually?

If this is possible, then you could:

1) report each asset as a test via service messages. Service messages are just messages in a special format that may be sent to stdout by your build process. When TeamCity detects one it will do some operation on the server side. 

Reporting assets as tests may help because TeamCity has a lot of functionality for test history analysis. You may, for instance, compare two builds to see if a test failure (broken asset) is a new case, or if it already happened before, you may set up build failure metrics, ignore certain tests if needed, and retrieve test data via REST API. However, the possible downside is the number of tests that you might report; if count of just problematic assets may reach more than thousand entries, I assume that total count of assets would be one or more magnitudes larger. This is quite a lot of test data per build; if you take this approach, I suggest that you set up reasonably aggressive cleanup rules for the project in question.

2) alternatively, you may consider generating a simple HTML report out of that data. TeamCity can show HTML reports as a custom tab on the build results, and you may format it so that it is more convenient for you to quickly access the problematic access and type/count of problems. 

It is also possible to create a custom TeamCity plugin for the same. 
If you would like any assistance with either of three, please let me know and I will try to assist further. 

Thank you so much Fedor for all the things you proposed. 
This is very helpful. 
I actually worked with the TeamCity HTML reporting in the past and i think it could be the best approach for our needs. 
I'll look into that!!

Thanks again!