Por que o PATH é diferente ao iniciar o escravo Jenkins via launchctl?

Question

Eu tenho um escravo Jenkins em execução no macOS por meio de ssh slave , depois screen e, em seguida, inicio o script a seguir, que garante a reconexão do servidor se ele ficar inativo:

#!/usr/bin/env bash

function startSlave() {
  java -jar /Users/user/slave.jar -jnlpUrl https://jenkins.company.com/computer/slave-office/slave-agent.jnlp -secret xyz
  sleep 3
}

startSlave

while true; do
  PID=$(pgrep "slave-agent.jnlp" | awk '{print $2}')
  if [[ -z $PID ]]; then
    echo "Jenkins slave has died, restarting..."
    startSlave
  fi
  sleep 60
done

Isso funciona muito bem, echo $PATH em um trabalho Jenkins é igual a executar echo $PATH em uma sessão de terminal que é aberta via ssh.

Às vezes, precisamos reiniciar a máquina, por isso quero que esse script seja executado no login. Eu testei iniciando o script via launchctl solution e App que está na lista de aplicativos de inicialização do usuário macOS.

Ambas as vezes echo $PATH do escravo Jenkins são iguais a: %código% Portanto, o PATH não está configurado corretamente para o usuário atualmente conectado.

• O processo está sendo executado sob as contas dos usuários
• Até mesmo o processo que o escravo Jenkins começa a executar na conta do usuário
• Usamos apenas /usr/bin:/bin:/usr/sbin:/sbin para configurar o ambiente vars ...

O que há de errado? Por que o escravo Jenkins não configura corretamente a variável PATH quando eu inicio o script acima via launchctl ou Application?

ATUALIZAÇÃO: Eu consegui trabalhar explicitamente perfil de sourcing no trabalho Jenkins: %código% Alguém sabe por que Jenkins-Slave não está fazendo isso automaticamente?

    

Answer 1

Eu não sei ao certo, mas meu primeiro palpite é que isso é porque o Jenkins não está lançando o subshell como um 'shell de login'. Quando você faz o login em um shell em um ambiente interativo, o shell carrega arquivos de ambiente de maneira diferente de quando é lançado através de um ambiente 'não interativo', como o cron. Para alterar esse comportamento e fazer com que seus ambientes 'combinem' com mais fidelidade, você precisará iniciar o subshell como um shell de login. Existem várias maneiras de fazer isso, e tenho certeza que o Jenkins tem uma maneira mais robusta, mas, no mínimo, você pode tentar mudar a primeira linha sh-bang para:

#!/bin/bash -l

Remova essa linha de fornecimento explícita do trabalho. Agora, veja se tudo funciona! :)

Para referência, dê uma olhada na seção longa e complexa da página man do bash "INVOCATION". link