Em primeiro lugar, passe o mouse sobre a área cinza abaixo. Não faz parte da resposta, mas tem que ser dito:
Se você tem um script de shell que faz "checkout, build, deploy" sozinho, por que está usando o Jenkins? Você está renunciando a todos os recursos do Jenkins que o tornam o que é. Você também pode ter um cron ou um gancho post-commit SVN para chamar o script diretamente. Jenkins realizar a própria verificação do SVN é crucial. Permite que as compilações sejam acionadas apenas quando houver alterações (ou no cronômetro, ou manual, se preferir). Ele mantém o controle das mudanças entre as compilações. Ele mostra essas mudanças, para que você possa ver qual construção foi para qual conjunto de mudanças. Ele envia um e-mail aos committers quando suas mudanças causam sucesso ou falha na construção (novamente, conforme configurado como você preferir). Ele enviará um e-mail aos committers quando suas correções consertarem a compilação com falha. E cada vez mais. O arquivamento dos artefatos pelo Jenkins também os torna disponíveis, por compilação, diretamente do Jenkins. Embora não seja tão crucial quanto o check-out do SVN, mais uma vez é parte integrante do que o torna Jenkins. Mesmo com a implantação. A menos que você tenha um único ambiente, a implantação geralmente acontece em vários ambientes. O Jenkins pode acompanhar em qual ambiente uma construção específica (com um conjunto específico de alterações de SVN) é implantada, por meio do uso de Promoções. Você está renunciando a tudo isso. Parece que disseram "você tem que usar o Jenkins", mas você realmente não quer, e está fazendo isso apenas para tirar seus chefes do seu pé, apenas para colocar uma marca de seleção "sim, usei o Jenkins"
A resposta curta é: o código de saída do último comando da etapa de compilação Execute Shell do Jenkin é o que determina o sucesso / falha da etapa de compilação . 0- sucesso, anything else- fracasso. Observe que isso está determinando o sucesso / falha da etapa de construção , não a execução de toda a tarefa . O sucesso / falha de toda a execução do job pode ser ainda mais afetado por várias etapas de construção e ações e plug-ins pós-construção.
Você mencionou Build step 'Execute shell' marked build as failure, então vamos nos concentrar apenas em uma única etapa de construção. Se sua etapa de compilação Executar shell tiver apenas uma linha que chama seu script de shell, o código de saída de seu script de shell determinará o sucesso / falha da etapa de compilação. Se você tiver mais linhas, após a execução do script de shell, revise-as cuidadosamente, pois são as que podem estar causando a falha.
Por fim, leia aqui o Jenkins Build Script sai após a execução do Google Test . Não está diretamente relacionado à sua pergunta, mas observe aquela parte sobre o Jenkins iniciar a etapa de compilação Execute Shell , como um script de shell com/bin/sh -xe
Os -emeios que o shell script vai sair com o fracasso, mesmo que apenas 1 comando falhar, mesmo se você fizer a verificação de erros para esse comando (porque as saídas de script antes que ele chegue à sua verificação de erros). Isso é contrário à execução normal de scripts de shell, que geralmente imprimem a mensagem de erro para o comando com falha (ou redirecionam para nulo e tratam por outros meios) e continuam.
Para contornar isso, adicione set +eao início de seu script de shell.
Como você diz que seu script faz tudo o que deve fazer, é provável que o comando com falha esteja em algum lugar no final do script. Talvez um eco final? Ou cópia de artefatos em algum lugar? Sem ver a saída completa do console, estamos apenas adivinhando.
Poste a saída do console da execução do job e, de preferência, o próprio script de shell também, e então poderemos dizer exatamente qual linha está falhando.