Estoy intentando utilizarlo virtualenvpara administrar mediante programación entornos Python para cada trabajo en un servidor Jenkins, implementado a través de unBiblioteca compartidaextensión para activar entornos por trabajo. P.ej:
/vars/activateEnvironment.groovy:
def call(String env = "/usr/local/etc/environments/jenkins-$JOB_NAME") {
sh """
mkdir ${env}
virtualenv ${env}
source ${env}/bin/activate
"""
}
Script de canalización, en el que el virtualenv-scriptsrepositorio contiene el archivo anterior:
@Library('virtualenv-scripts') _
pipeline {
agent any
stages {
stage("Test") {
steps {
activateEnvironment()
sh 'which pip'
sh 'echo \$PATH'
}
}
}
}
Al ejecutar este script de canalización, obtengo el siguiente resultado:
[Pipeline] sh
[example-pipeline] Running shell script
+ echo /sbin:/usr/sbin:/bin:/usr/bin
/sbin:/usr/sbin:/bin:/usr/bin
[Pipeline] sh
[example-pipeline] Running shell script
+ which pip
/bin/pip
He intentado usaresta respuestapara que Jenkins use un shell de inicio de sesión, pero eso aún recarga el entorno con cada shllamada.
yo también viesta respuestalo que requeriría pegar texto adicional cada vez que shse usa un paso en una canalización, lo que no es ideal.
¿Existe una buena manera de hacer que el entorno persista entre shcomandos? Alternativamente, ¿existe una mejor manera de lograr entornos por trabajo con virtualenv? ¡Gracias por toda la ayuda/sugerencias!
Respuesta1
Tuve el mismo problema. Después de hablar con algunos administradores veteranos de Jenkins, esta es la solución a la que llegué:
def runCommandInMyEnvironment(cmd) {
sh "setup_environment_command; source ./some/file; ${cmd}"
}
pipeline {
agent any
stages {
stage("My Stage") {
steps {
runCommandInMyEnvironment('first_command')
runCommandInMyEnvironment('second_command')
// and so on
}
}
}
}
No es bonito y puede enturbiar bastante la salida de la consola, pero también es la forma más confiable de hacerlo.
Otro enfoque sería analizar el resultado de algún comando y dividirlo en un montón de variables de entorno y luego pasarlas a un withEnvbloque, pero este puede ser un enfoque muy complicado y poco confiable.
En cualquier caso, como mencionaste, Jenkins no admite entornos persistentes sin withEnv, por lo que, en última instancia, no existe una forma realmente buena o limpia de hacerlo.
Puede que haya una mejor manera de usar virtualenvs con Jenkins, pero nunca he escrito un trabajo de Jenkins que ejecute tareas en un virtualenv, así que no puedo decirlo. Hayeste complemento, perootra respuesta de desbordamiento de pilasugiere que el enfoque que proporcioné en esta respuesta es el método preferido para trabajar con entornos virtuales en Jenkins.