Os comandos bash são executados no terminal, mas não no script Jenkins / Bash

Question

Estou usando o Jenkins para criar e implantar a documentação em HTML em um servidor da web local Apache para que nossos desenvolvedores usem. Quando eu executo os comandos no terminal, tudo é instalado corretamente (Provando que o servidor está configurado corretamente). No entanto, quando os mesmos comandos são executados no Jenkins, eles são chamados, mas nada muda. Ele não exclui html.zip (Linha 18), não move os arquivos para /var/html/www/subdir e não relata erros fora da solicitação de curl . Estou um pouco perdida com o que estou fazendo errado.

Devo observar que estou chamando este script inteiro como sudo . Eu sei que isso é inseguro, mas imaginei que tentaria fazer o script funcionar primeiro, depois mude depois. Para garantir que user não tenha problemas ao instalar a documentação, eu permiti temporariamente que ele executasse qualquer comando como sudo sem uma senha. Mais uma vez, sei que isso é inseguro, mas no espírito de tentar eliminar variáveis, acrescentei isso.

Jenkins chama esse script assim: sudo ./documentation-publisher.sh

As permissões no script são as menos restritivas por enquanto, 777. Chamando ls -l nos relatórios de script: -rwxrwxrwx 1 devop developers 1144 Dec 3 10:29 documentation-publisher.sh

Eu tentei uma sugestão de este post sobre configurar explicitamente o caminho no script, mas não notou diferenças. Um caminho explícito para cada um dos comandos usados também não altera o comportamento.

#!/bin/sh -x

echo "Archiving generated HTML for transfer..."
cd Example/docs/html/
zip -r html.zip ./
scp -i ~/.ssh/id_rsa html.zip [email protected]:/home/user 
ssh -i ~/.ssh/id_rsa [email protected] 

echo "Extracting generated HTML into www directory..."
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
unzip -o html.zip -d ./subdir
rm -r /var/www/html/subdir
mkdir /var/www/html/subdir
cp -r ./subdir/* /var/www/html/subdir/

echo "Cleaning up after file transfer..."
rm -rf ./subdir 
rm ./html.zip 

echo "Testing install..."
curl -f my.host.example.com/subdir/index.html 
exit 

O que eu poderia estar fazendo de errado?

    

Answer 1

Parece que você deseja ssh em my.host.example.com e, em seguida, o restante do script é executado nesse host. Se esse for o caso, você precisará passar o restante do script como entrada para o comando ssh ; como é agora, ssh está recebendo entrada do stdin do script que provavelmente está vazio, então ele abre uma sessão de shell remota, envia um final de arquivo, que fecha a sessão ssh e executa o restante do script localmente . Para executar esses comandos remotamente, você precisa passá-los como entrada para o comando ssh , algo assim:

ssh -i ~/.ssh/id_rsa [email protected] <<EOF

echo "Extracting generated HTML into www directory..."
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
[...]
exit
EOF

Em segundo lugar, o script não tem verificação de erros. Em geral, é uma boa ideia examinar cada comando em um script e perguntar a si mesmo o que aconteceria se falhasse. Deveria o resto do roteiro continuar, ou seria "fugir dos trilhos" e fazer algo bobo? Por exemplo, se o comando scp falhar (por qualquer motivo), não há motivo para executar o restante do script (e isso pode ser destrutivo, eliminando / var / www / html / subdir e então substituindo por ... oops, nada). Você pode executar uma verificação de erro no status de saída de cada comando individual, algo como:

scp -i ~/.ssh/id_rsa html.zip [email protected]:/home/user || {
    echo "Failed to scp the html files to my.host.example.com." >&2
    exit 1
}

... ou use a opção -e do shell para fazê-lo sair do script se o comando any falhar. Essa opção evita que você tenha que verificar o erro de cada comando individualmente, mas não fornece mensagens de erro informativas e pode causar problemas ao sair do script se algo que não importa retornar um status de erro por algum motivo (consulte BashFAQ # 105 para alguns exemplos de porque -e pode causar comportamento inesperado). Além disso, se você usar essa opção, use set -e no início do script (ou use -xe na linha shebang), e adicione set -e como primeiro comando enviado para o computador remoto.

BTW, o comando cd na linha 4 é particularmente provável de falhar, pois usa um caminho relativo. Isso significa que o diretório para o qual ele tenta cd depende do diretório de trabalho do qual o script foi iniciado. Note que este não é necessariamente o diretório em que o script está, ele é herdado do processo que iniciou o script e, portanto, pode ser quase qualquer coisa. Jenkins pode estar iniciando o script com um diretório de trabalho diferente do seu, fazendo com que ele falhe logo no início. Bem, na verdade não falha, apenas execute todos os comandos restantes no diretório errado (e por causa do problema ssh input, no host errado).

    

Answer 2

Quando você copia, exclui ou move arquivos, modifique seu script para usar um caminho absoluto. Atualmente você tem essas linhas

rm ./html.zip cp -r ./subdir/* /var/www/html/subdir/

altere a parte ./ para o caminho completo para esse arquivo ou diretório.