2015-09-17 6 views
5

Ich habe 2 RHEL-Maschinen in einer Master/Slave-Konfiguration mit Jenkins ver. 1.609.2Wie zum Slave PATH mit Slave SetupPlugin hinzufügen?

Der Slave wird über SSH Slaves Plugin 1.10 gestartet.

Ich versuche, die Slave Setup Plugin v 1.9 zu verwenden, um die Tools zu installieren, die für meine Slave-Maschine benötigt werden, um Builds auszuführen. Insbesondere installiere ich sqlplus. Hier

ist das Skript, das ich um leite, um zu versuchen die Installation von sqlplus:

if command -v sqlplus >/dev/null; then 
    echo "sqlplus already setup. Nothing to do." 
else 
    #Create directory for sqlplus and unzip it there. 
    mkdir /jenkins/tools/sqlplus 
    tar -xvf sqlplussetup/instantclient-basiclite-linux.x64-12.1.0.2.0.tar.gz -C /jenkins/tools/sqlplus || { echo 'unzip failed' ; exit 1; } 
    tar -xvf sqlplussetup/instantclient-sqlplus-linux.x64-12.1.0.2.0.tar.gz -C /jenkins/tools/sqlplus || { echo 'unzip failed' ; exit 1; } 

    cd /jenkins/tools/sqlplus/instantclient_12_1 

    #Create links for the Oracle libs 
    ln -s libclntsh.so.12.1 libclntsh.so || { echo 'Could not create link' ; exit 1; } 
    ln -s libocci.so.12.1 libocci.so || { echo 'Could not create link' ; exit 1; } 

    #Add two lines to .bashrc only if they don't already exist. Export LD_LIBRARY_PATH and add sqlplus to PATH. 
    grep -q -F 'export LD_LIBRARY_PATH=/jenkins/tools/sqlplus/instantclient_12_1:$LD_LIBRARY_PATH' /home/jenkins/.bashrc || echo 'export LD_LIBRARY_PATH=/jenkins/tools/sqlplus/instantclient_12_1:$LD_LIBRARY_PATH' >> /home/jenkins/.bashrc 
    grep -q -F 'export PATH=$PATH:/jenkins/tools/sqlplus/instantclient_12_1' /home/jenkins/.bashrc || echo 'export PATH=$PATH:/jenkins/tools/sqlplus/instantclient_12_1' >> /home/jenkins/.bashrc 

    #Export variables so they can be used right away 
    export LD_LIBRARY_PATH=/jenkins/tools/sqlplus/instantclient_12_1:$LD_LIBRARY_PATH 
    export PATH=$PATH:/jenkins/tools/sqlplus/instantclient_12_1 

    echo "sqlplus has been setup." 
fi 

Dieses Skript läuft erfolgreich und alles scheint zu funktionieren, bis ich versuche, einen Build auszuführen und den sqlplus Befehl auszuführen. Der Build schlägt fehl, weil sqlplus kein anerkannter Befehl ist.

Meine Hauptfrage ist: Was ist der richtige Weg, um automatisch eine Umgebungsvariable beim Start eines Slave hinzuzufügen?

Bitte beachten Sie, ich bin auf der Suche nach einem automatisierten Weg dies zu tun. Ich möchte nicht in den Konfigurationsbildschirm für meinen Slave gehen, ein Kontrollkästchen ankreuzen und eine Umgebungsvariable angeben. Das ist kontraproduktiv zu dem, was ich zu erreichen versuche, welches ein Slave ist, der sofort für Builds verwendet werden kann, sobald er verbunden ist.


Ich verstehe ziemlich gut, warum mein Skript nicht funktioniert. Wenn Jenkins ist die Slave-Start macht es zuerst eine Verbindung SSH und dann läuft es meinen Setup-Skript

/bin/sh -xe /jenkins/tmp/hudson8035138410767957141.sh 

den Befehl Wo der Inhalt von hudson8035138410767957141.sh mein Skript von oben ist. So offensichtlich, die exportisn't going to work. Ich hatte gehofft, das Hinzufügen der Exporte in die Datei .bashrc würde dies umgehen, aber es funktioniert nicht. I denke, ist dies, weil dieses Skript ausgeführt wird, nachdem die SSH-Verbindung hergestellt wurde und daher die .bashrc bereits gelesen wurde.

Problem ist, ich kann keine Möglichkeit finden, diese Einschränkung zu umgehen.

+0

Wir verwenden https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin zum Einrichten von Variablen, bevor Sie aktuelle Jobs ausführen. Wenn Sie einige Konventionen über Installationen befolgen, könnte dies hilfreich sein. – Jayan

Antwort

1

Bash liest keine seiner Startup-Dateien (.bashrc, .profile usw.) für nicht-interative Shells, für die die Option --login nicht explizit festgelegt wurde - deshalb funktionieren die Exporte nicht.

So Lösung „A“ ist die bashrc Magie zu halten, die Sie oben vorschlagen, und die --login Option hinzufügen, indem Sie die erste Zeile in Ihrem Build-Schritt Wechsel zu

#!/bin/bash --login 

<your script here> 

Den expliziten shebang an auf der Die erste Zeile verhindert außerdem eine übermäßige Debug-Ausgabe, die Sie von der Standardoption -x erhalten (siehe oben in der Konsole).

Alternative Lösung "B" verwendet die Tatsache, dass bash jedes Skript mit dem Namen $BASH_ENV (wenn diese Variable definiert ist und die Datei existiert). Definieren Sie diese Variable global in Ihren Slave-Eigenschaften (z. B. auf /jenkins/tools/setup.sh) und fügen Sie bei Bedarf während des Slave-Setups Exporte hinzu. Jeder Schritt zum Erstellen einer Bash Shell liest dann die Einstellungen.

Mit der Lösung "B" müssen Sie nicht die Option --login verwenden und Sie müssen nicht die .bashrc durcheinander bringen. Die Funktion "BASH_ENV" ist jedoch nur aktiv, wenn bash im "bash mode" läuft. Als Jenkins die Shell über sh startet, versucht bash, historisches sh zu emulieren, das diese Funktion nicht hat. Also, auch für B, benötigen Sie einen shebang:

#!/bin/bash 

<your script here> 

Aber, dass Sie irgendwie erhalten bräuchten loszuwerden, die Verfolgungsausgabe, die in der Produktion Setups in der Regel zu viel.

+0

Ich mag Ihre Lösung "B". Wenn ich richtig verstehe, wenn ich "PATH" und "LD_LIBRARY_PATH" innerhalb des '$ BASH_ENV'-Skripts exportieren würde, würden diese während des Build-Schritts bleiben? Leider arbeite ich nicht mehr an dem Projekt, das dies erfordert, also kann ich es nicht wirklich testen. – FGreg

+0

Ja. Befehle/Exporte in '$ BASH_ENV' werden während des Bash-Starts gelesen und bleiben für die gesamte Shell-Sitzung erhalten - genau wie für Anweisungen, die Sie zu' .bashrc' usw. für interaktive Login-Shells hinzufügen. –