Lo primero es lo primero, pase el mouse sobre el área gris a continuación. No es parte de la respuesta, pero es absolutamente necesario decirlo:
Si tiene una secuencia de comandos de shell que hace "pago, compilación, implementación" por sí sola, ¿por qué está usando Jenkins? Está renunciando a todas las características de Jenkins que lo convierten en lo que es. También puede hacer que un cron o un enlace posterior a la confirmación de SVN llame al script directamente. Que Jenkins realice la comprobación de SVN en sí es crucial. Permite que las compilaciones se activen solo cuando hay cambios (o en el temporizador o manual, si lo prefiere). Realiza un seguimiento de los cambios entre compilaciones. Muestra esos cambios, para que pueda ver qué compilación fue para qué conjunto de cambios. Envía correos electrónicos a los confirmantes cuando sus cambios causaron una compilación exitosa o fallida (nuevamente, según lo configurado como prefiera). Enviará un correo electrónico a los confirmadores cuando sus soluciones solucionen la compilación defectuosa. Y cada vez más. Jenkins archiva los artefactos también los hace disponibles, por construcción, directamente de Jenkins. Si bien no es tan crucial como la verificación de SVN, esto es una vez más una parte integral de lo que lo convierte en Jenkins. Lo mismo ocurre con la implementación. A menos que tenga un único entorno, la implementación suele ocurrir en varios entornos. Jenkins puede realizar un seguimiento de en qué entorno se implementa una compilación específica (con un conjunto específico de cambios de SVN), mediante el uso de Promociones. Estás renunciando a todo esto. Parece que te dicen "tienes que usar Jenkins", pero en realidad no quieres, y lo estás haciendo solo para quitarte de encima a tus jefes, solo para marcar "sí, he usado Jenkins"
La respuesta corta es: el código de salida del último comando del paso de compilación Ejecutar Shell de Jenkin es lo que determina el éxito / fracaso del Paso de compilación . 0- éxito, anything else- fracaso. Tenga en cuenta que esto determina el éxito / fracaso del paso de compilación , no la ejecución completa del trabajo . El éxito / fracaso de toda la ejecución del trabajo puede verse afectado aún más por varios pasos de compilación y acciones y complementos posteriores a la compilación.
Como ha mencionado Build step 'Execute shell' marked build as failure, nos centraremos en un solo paso de compilación. Si su paso de construcción Ejecutar shell solo tiene una línea que llama a su script de shell, entonces el código de salida de su script de shell determinará el éxito / fracaso del paso de construcción. Si tiene más líneas, después de la ejecución del script de shell, revíselas cuidadosamente, ya que son las que podrían estar causando fallas.
Finalmente, lea aquí Jenkins Build Script sale después de la ejecución de Google Test . No está directamente relacionado con su pregunta, pero tenga en cuenta esa parte sobre el lanzamiento de Jenkins del paso de compilación Ejecutar Shell , como un script de shell con/bin/sh -xe
Los -emedios que el script de shell salir con el fracaso, incluso si sólo 1 comando falla, incluso si lo hace la comprobación de errores para ese comando (porque las salidas de guión antes de que llegue a su comprobación de errores). Esto es contrario a la ejecución normal de los scripts de shell, que generalmente imprimen el mensaje de error del comando fallido (o lo redirigen a nulo y lo manejan por otros medios) y continúan.
Para evitar esto, agregue set +ea la parte superior de su script de shell.
Como dice que su secuencia de comandos hace todo lo que se supone que debe hacer, es probable que el comando que falla esté en algún lugar al final de la secuencia de comandos. ¿Quizás un eco final? ¿O copia de artefactos en alguna parte? Sin ver la salida completa de la consola, solo estamos adivinando.
Publique la salida de la consola de la ejecución del trabajo, y preferiblemente también el script de shell, y luego podríamos decirle exactamente qué línea está fallando.