Auto assign user when build step fails

[Sharken03]

The plugin does not seem to Auto assign users when a build step fails, only when a test failure is encountered. But even then, we can't see any of the INFO messages from either the BuildProblemsAssigner or the FailedTestAssigner class.

This is with TeamCity 2017.2.4

[rugpanov]

Hi! Thank you for your report. Unfortunately for some reasons the plugin processes only compilation build problems currently. Were your build problems compilation ones?

I'll try to reproduce the second issue to fix it. Did I understand you correctly that you couldn't see any logs from the plugin at all?

[Sharken03]

The build problem was from a Metarunner and the build step that failed was a simple Cmd runner returning exit code 1. The build step itself is compiling the code, so it fails if the checked-in code is not in a working condition.

There is output in the teamcity-server logs, after enabling Debug these lines appear:

[2018-06-21 01:20:27,680] DEBUG - dTestAndBuildProblemsProcessor - Start processing build #27244. [2018-06-21 01:20:27,684] DEBUG - dTestAndBuildProblemsProcessor - Build #27244: has 1 build problems and 1 failed tests. [2018-06-21 01:20:27,690] DEBUG - processing.BuildProblemsFilter - Build problem 27244:Build failure condition is not applicable. [2018-06-21 01:20:27,690] DEBUG - dTestAndBuildProblemsProcessor - Build #27244: found 0 applicable build problems and 0 applicable failed tests. [2018-06-21 01:20:27,690] DEBUG - TestAndBuildProblemsDispatcher - Build #27244 removed from processing.

Here it would be nice if the reasoning was visible, as in why are the build problem and failed test not applicable. I can't remember seeing the LOGGER.info() text in the logs, but since LOGGER.debug is visible i would think it is possible for those logs to appear.

And finally the heuristics text such as "...you were responsible for the build problem..." does show up in the logs.

UPDATE: Looking at http://javadoc.jetbrains.net/teamcity/openapi/current/jetbrains/buildServer/BuildProblemTypes.html#TC_COMPILATION_ERROR_TYPE i think that the type TC_EXIT_CODE_TYPE should also be among the supported types in the BuildProblemsFilter class.

UPDATE 2: The file FailedTestAndBuildProblemsProcessor.java uses a wrong variable in line 69: LOGGER.debug("Build #" + sBuild.getBuildId() + ": has " + allBuildProblems.size() + " build problems and " + allBuildProblems.size() + " failed tests.");

The second line should use allFailedTests.size().

[rugpanov]

First of all you made a great job with collecting logs and exploring source code. Thank you.

Unfortunately this behavior is designed - there is a common TeamCity problem that assignment of investigation for build problem with exit code 1 is applied for whole the build-server. So we decided not to auto-assign investigations for this particular problem.

So your feature request is add more information into the log about decision making whether we should process/not process the problem/failed test and add assignment text into the log, am I correct? We definitely should do this.

According to the second update: yes, it seems it's a bug. I'll fix it.

[Sharken03]

@rugpanov Yes, you have summed up the feature request perfectly.

Is there a workaround where we could return another exit code, that the plugin would act upon ?

[rugpanov]

@Sharken03 , as we discussed I implemented extra logging for filtering.

From my perspective in your case it's reasonable to use reporting compilation messages.

[Sharken03]

Have updated the plugin to the latest version (build 29), and will try to report back on how it went. Thank you for insights into how to make this plugin work better.

Our metarunner that builds the solution is now using Reporting compilation messages, although it still feels unnecessary when the exit code signals there is an error. If TeamCity could ever improve upon that, it would be a very welcome addition.

[Sharken03]

Am leaving some feedback as it might be of interest to others. With debug logging enabled, this is what was logged to the Teamcity-server log.

[2018-06-22 10:55:01,129]  DEBUG - dTestAndBuildProblemsProcessor - Start processing build #27410. 
[2018-06-22 10:55:01,168]  DEBUG - dTestAndBuildProblemsProcessor - Build #27410: has 1 build problems and 2 failed tests. 
[2018-06-22 10:55:01,176]  DEBUG - processing.BuildProblemsFilter - Build problem 27410:Build failure condition is not applicable. Reason: this build problem has an unsupported type TC_FAILED_TESTS. Supported types: [TC_COMPILATION_ERROR]. 
[2018-06-22 10:55:01,178]  DEBUG - aa.processing.FailedTestFilter - Test problem 27410:Server.dll: Server.Test1 is applicable. 
[2018-06-22 10:55:01,178]  DEBUG - aa.processing.FailedTestFilter - Test problem 27410:Server.dll: Server.Test2 is applicable. 
[2018-06-22 10:55:01,178]  DEBUG - dTestAndBuildProblemsProcessor - Build #27410: found 0 applicable build problems and 2 applicable failed tests. 
[2018-06-22 10:55:01,178]  DEBUG - uristics.OneCommitterHeuristic - There are no committers since last build for failed build #27410 
[2018-06-22 10:55:01,201]   INFO - .processing.FailedTestAssigner - Found responsible for CustomerProject1 {internalId=project1, externalId=CustomerProject1}#Server.dll: Server.Test1:: user: teamcitysupport because of "Auto-assigned investigation: you're the default responsible user for the build: CustomerProject1 :: Full #311" 
[2018-06-22 10:55:01,206]  DEBUG - .impl.ResponsibilityFacadeImpl - Investigation updated for 1 test in project CustomerProject1 {internalId=project1, externalId=CustomerProject1}, Test Investigation {state: TAKEN, timestamp: 2018-06-22 10:55:01.202, assignee: 'teamcitysupport' {id=90}, comment: "Auto-assigned investigation: you're the default responsible user for the build: CustomerProject1 :: Full #311", reporter: <null>, test name: Server.dll: Server.Test1test id: -6400952494077613601, project: CustomerProject1 {internalId=project1, externalId=CustomerProject1}} 
[2018-06-22 10:55:01,213]   INFO - .processing.FailedTestAssigner - Found responsible for CustomerProject1 {internalId=project1, externalId=CustomerProject1}#Server.dll: Server.Test2:: user: teamcitysupport because of "Auto-assigned investigation: you're the default responsible user for the build: CustomerProject1 :: Full #311" 
[2018-06-22 10:55:01,228]  DEBUG - .impl.ResponsibilityFacadeImpl - Investigation updated for 1 test in project CustomerProject1 {internalId=project1, externalId=CustomerProject1}, Test Investigation {state: TAKEN, timestamp: 2018-06-22 10:55:01.213, assignee: 'teamcitysupport' {id=90}, comment: "Auto-assigned investigation: you're the default responsible user for the build: CustomerProject1 :: Full #311", reporter: <null>, test name: Server.dll: Server.Test2test id: 8623722774884028433, project: CustomerProject1 {internalId=project1, externalId=CustomerProject1}}

Some comments:
* Failed tests are marked as TC_FAILED_TESTS, and thus ignored by the BuildProblemsFilter.
* Failed tests are handled by the FailedTestFilter as intended.
* Even though there was only 1 changeset leading to this error, the catch-all user was selected, due to missing link from VCS Username to TeamCity user.

[Sharken03]

@rugpanov Could you elaborate a bit about your comment above that says

Unfortunately this behavior is designed - there is a common TeamCity problem that assignment of investigation for build problem with exit code 1 is applied for whole the build-server. So we decided not to auto-assign investigations for this particular problem.

Whenever a build is failing with exit code 1, we have to send the compilationStarted service message with status='error', which in the Overview produces two nodes: One rather useless called "Compilation error" and a more useful one called "Build failure condition". If we would like to have just one error, could we for example exit with the exit code 2 instead ?

[rugpanov]

Sharken03 , No, it won't work. But probably we can fix it. Can you create a feature request for supporting EXIT_CODE build problems?

[Sharken03]

Yes of course, i will create a feature request.