build - Teamcity ejecuta los pasos de compilación incluso cuando las pruebas fallan
mstest (5)
Estoy teniendo problemas con Teamcity , donde se está ejecutando los pasos de compilación incluso si los anteriores no tuvieron éxito.
El último paso de la configuración de mi compilación implementa mi sitio, que no quiero que haga si falla alguna de mis pruebas.
Cada paso de compilación está configurado para ejecutarse solo si todos los pasos anteriores fueron exitosos.
En la pestaña Condiciones de falla de compilación, verifiqué las siguientes opciones en Fallar compilación si:
-build process exit code is not zero
-at least one test failed
-an out-of-memory or crash is detected (Java only)
Esto no funciona, incluso cuando las pruebas fallan, TeamCity implementa mi sitio, ¿por qué?
Incluso intenté agregar una condición de falla de compilación adicional que buscará un texto específico en el registro de compilación (a saber, "Fallo en la ejecución de la prueba").
Al ver una prueba completada en la página de resumen, puede ver el mensaje de error en la última compilación:
"Falló la ejecución de la prueba". el texto apareció en el registro de compilación
Pero todavía lo despliega de todos modos.
¿Alguien sabe cómo arreglar esto? Parece que el problema ha estado funcionando durante mucho tiempo, here .
Al parecer hay una solución:
Hasta ahora no consideramos que esta característica sea muy importante, ya que existe una solución obvia: el script puede verificar la condición necesaria y no producir los artefactos tal como están configurados en TeamCity.
por ejemplo, una secuencia de comandos puede mover los artefactos de un directorio temporal al directorio especificado en TeamCity, ya que publica artefactos justo antes del final y en caso de que las operaciones de compilación hayan sido exitosas.
Pero eso no me queda claro exactamente cómo hacerlo, y tampoco suena como la mejor solución. Cualquier ayuda apreciada.
Edición : también pude solucionar el problema con una dependencia de instantáneas, donde tendría una compilación de ''despliegue'' independiente que dependía de la compilación de prueba, y ahora no se ejecuta si las pruebas fallan.
This fue útil para configurar la dependencia.
Al final, pude resolver el problema con una dependencia de instantáneas, donde tendría una compilación de ''despliegue'' independiente que dependía de la compilación de prueba, y ahora no se ejecuta si las pruebas fallan.
This fue útil para configurar la dependencia.
Este es un problema conocido a partir de TeamCity 7.1 (consulte http://youtrack.jetbrains.com/issue/TW-17002 ) que se ha corregido en TeamCity 8.x + (consulte esta respuesta ).
TeamCity distingue entre una compilación fallida y un paso de compilación fallido. Si bien una prueba unitaria fallida fallara la compilación en su totalidad, desafortunadamente TeamCity aún considera que el paso de la prueba fue exitoso porque no devolvió un código de error distinto de cero . Como resultado, los pasos posteriores continuarán ejecutándose.
Se han propuesto una variedad de soluciones, pero he descubierto que requieren una configuración no trivial o un compromiso con la experiencia de prueba en TeamCity.
Sin embargo, después de revisar una sugerencia de @ arex1337 , encontramos una manera fácil de hacer que TeamCity haga lo que queremos. Solo agregue un paso de compilación de Powershell adicional después de su paso de prueba existente que contenga la siguiente secuencia de comandos en línea (reemplazando YOUR_TEAMCITY_HOSTNAME con su host / dominio de TeamCity real):
$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"
}
Esta secuencia de comandos de PowerShell en línea solo está utilizando la API REST de TeamCity para preguntar si la compilación en sí misma, en su totalidad, se considera fallida (la variable %teamcity.build.id%" será reemplazada por TeamCity con el id de compilación real cuando el se ejecuta el paso). Si la compilación en su totalidad se considera fallida (por ejemplo, debido a un error de prueba), esta secuencia de comandos de PowerShell produce un error, lo que hace que el proceso devuelva un código de error distinto de cero que da como resultado el paso de compilación individual se considera que no tiene éxito . En ese punto, se pueden evitar los pasos subsiguientes.
Tenga en cuenta que esta secuencia de comandos utiliza guestAuth, que requiere que la cuenta de invitado de TeamCity esté habilitada. Alternativamente, puede usar httpAuth en su lugar, pero deberá 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 subsiguientes configurados para ejecutarse "Solo si todos los pasos anteriores fueron exitosos" se omitirán si hay fallas de pruebas de unidades previas. Estamos usando esto para evitar la implementación automatizada si cualquiera de nuestras pruebas NUnit no es exitosa hasta que JetBrains solucione el problema.
Esto es (como ha encontrado) un problema conocido con TeamCity, hay un conjunto de http://youtrack.jetbrains.com/issue/TW-17002 en su Rastreador de problemas. Es de esperar que este problema esté programado para resolverse en la próxima versión de TeamCity (versión 8.x)
Mientras tanto, la forma en que identificamos para resolver el problema (para la versión 6.5.5) fue descargar el archivo de resultados de la prueba como parte de los pasos posteriores. Luego se analizó para verificar si hay fallas en las pruebas, devolver un código de error y, por lo tanto, romper la compilación correctamente (realizar cualquier limpieza que necesitemos como parte de esa falla) que probablemente funcionaría para usted.
La falla de compilación de TeamCity no significa que detendrá la compilación y publicará los artefactos si su compilación proporciona los archivos de salida de compilación como lo requiere TeamCity. Solo actualizará el estado de compilación correctamente.
Pero, puede muy bien detener el proceso de compilación mediante la modificación de su secuencia de comandos de compilación para detener la compilación en caso de fallo del caso de prueba. Si está utilizando MSBuild, entonces ContinueOnError="false" lo hará.
Solo para evitar confusiones, este problema se soluciona en Team City v8.x. No necesitamos esas soluciones ahora.
Puede especificar la política de ejecución de pasos a través de la opción Ejecutar paso:
Solo si el estado de compilación es exitoso : antes de comenzar el paso, el agente de compilación solicita el estado de compilación al servidor y omite el paso si el estado falla.
https://confluence.jetbrains.com/display/TCD8/Configuring+Build+Steps
Por supuesto, debe fallar la compilación si falla al menos una prueba de unidad:
https://confluence.jetbrains.com/display/TCD8/Build+Failure+Conditions
En la página Condiciones de falla de compilación, el área Fallo de compilación, especifique cuándo TeamCity fallará las compilaciones:
al menos una prueba falló : marque esta opción para marcar la compilación como fallida si la compilación falla al menos una prueba.