Teamcity ejecuta pasos de compilación incluso cuando las pruebas fallan

Este es un problema conocido en TeamCity 7.1 (cf. http://youtrack.jetbrains.com/issue/TW-17002 ) que se ha corregido en TeamCity 8.x+ (ver esta respuesta).

TeamCity distingue entre una compilación fallida y una compilación fallida . Si bien una prueba unitaria fallida fallará la compilación en su conjunto, desafortunadamente TeamCity todavía considera que el paso de prueba en sí tuvo éxito porque no devolvió un código de error distinto de cero. Como resultado, posterior los pasos continuarán corriendo.

Se han propuesto una variedad de soluciones, pero he encontrado que requieren una configuración no trivial o un compromiso en la experiencia de prueba en TeamCity.

Sin embargo, después de revisar una sugerencia de @arex1337, encontramos una manera fácil de conseguir que TeamCity haga lo que queremos. Simplemente agregue un paso adicional de compilación de Powershell después del paso de prueba existente que contenga el siguiente script en línea (reemplazando YOUR_TEAMCITY_HOSTNAME con su TeamCity real host / dominio):

$request = [System.Net.WebRequest]::Create("http://YOUR_TEAMCITY_HOSTNAME/guestAuth/app/rest/builds/%teamcity.build.id%")
$xml = [xml](new-object System.IO.StreamReader $request.GetResponse().GetResponseStream()).ReadToEnd()
Microsoft.PowerShell.Utility\Select-Xml $xml -XPath "/build" | % { $status = $_.Node.status }

if ($status -eq "FAILURE") {
    throw "Failing this step because the build itself is considered failed. This is our way to workaround the fact that TeamCity incorrectly considers a test step to be successful even if there are test failures. See http://youtrack.jetbrains.com/issue/TW-17002"
}

Este script inline de PowerShell solo usa la API REST de TeamCity para preguntar si la compilación en sí, como un todo, se considera fallida (la variable %teamcity.build.id%" será reemplazada por TeamCity con el id de compilación real cuando se ejecute el paso). Si la compilación en su conjunto se considera fallida (por ejemplo, debido a un error de prueba), este script de PowerShell genera un error, lo que hace que el proceso devuelva un código de error distinto de cero que da lugar al paso de compilación individual en sí mismo para ser considerado infructuoso . En ese momento, se puede evitar que se ejecuten los pasos posteriores.

Tenga en cuenta que este script utiliza guestAuth, que requiere que la cuenta de invitado de TeamCity esté habilitada. Alternativamente, puede usar httpAuth en su lugar, pero necesitará actualizar el script para incluir un nombre de usuario y contraseña de TeamCity (por ejemplo, http://USERNAME:PASSWORD@YOUR_TEAMCITY_HOSTNAME/httpAuth/app/rest/builds/%teamcity.build.id%).

Por lo tanto, con este paso adicional en su lugar, todos los pasos posteriores configurados para ejecutarse "Solo si todos los pasos anteriores fueron exitosos" se omitirán si hay algún fallo de la prueba unitaria anterior. Estamos usando esto para evitar la implementación automatizada si alguna de nuestras pruebas de NUnit no tiene éxito hasta que JetBrains solucione el problema.

Gracias a @arex1337 por la idea.