Solución:
Una forma de cargar variables de entorno desde un archivo es cargar un archivo Groovy.
Por ejemplo:
- Digamos que tiene un archivo maravilloso en ‘$ JENKINS_HOME / .envvars’ llamado ‘stacktest-staging.groovy’.
-
Dentro de este archivo, define 2 variables de entorno que desea cargar
env.DB_URL="hello" env.DB_URL2="hello2"
-
Luego puede cargar esto usando
load "$JENKINS_HOME/.envvars/stacktest-staging.groovy"
-
Luego, puede usarlos en los siguientes pasos de eco / shell.
Por ejemplo, aquí hay un breve script de canalización:
node {
load "$JENKINS_HOME/.envvars/stacktest-staging.groovy"
echo "${env.DB_URL}"
echo "${env.DB_URL2}"
}
De los comentarios a la respuesta aceptada
No use global ‘env’, pero use la construcción ‘withEnv’, por ejemplo, vea: problema # 9: no establezca env vars con env global en las 10 mejores prácticas del complemento de canalización de jenkins
En el siguiente ejemplo: VAR1 es una cadena simple de Java (sin expansión de variables maravillosas), VAR2 es una cadena maravillosa (por lo que la variable ‘someGroovyVar’ se expande).
El script pasado es una cadena java simple, por lo que $ VAR1 y $ VAR2 se pasan literalmente al shell, y los ecos acceden a las variables de entorno VAR1 y VAR2.
stage('build') {
def someGroovyVar="Hello world"
withEnv(['VAR1=VALUE ONE',
"VAR2=${someGroovyVar}"
]) {
def result = sh(script: 'echo $VAR1; echo $VAR2', returnStdout: true)
echo result
}
}
Para secretos / contraseñas, puede usar el complemento de vinculación de credenciales
Ejemplo:
NOTA: CREDENTIALS_ID1 es un nombre de usuario / contraseña secreto registrado en la configuración de Jenkins.
stage('Push') {
withCredentials([usernamePassword(
credentialsId: 'CREDENTIALS_ID1',
passwordVariable: 'PASSWORD',
usernameVariable: 'USER')]) {
echo "User name: $USER"
echo "Password: $PASSWORD"
}
}
La salida del registro de la consola jenkisn oculta los valores reales:
[Pipeline] echo
User name: ****
[Pipeline] echo
Password: ****
Jenkins y las credenciales son un gran problema, probablemente vea: complemento de credenciales
Para completar: la mayoría de las veces, necesitamos los secretos en las variables de entorno, ya que los usamos de los scripts de shell, por lo que combinamos withCredentials y withEnv de la siguiente manera:
stage('Push') {
withCredentials([usernamePassword(
credentialsId: 'CREDENTIALS_ID1',
passwordVariable: 'PASSWORD',
usernameVariable: 'USER')]) {
withEnv(["ENV_USERNAME=${USER}",
"ENV_PASSWORD=${PASSWORD}"
]) {
def result = sh(script: 'echo $ENV_USERNAME', returnStdout: true)
echo result
}
}
}
Otra forma de resolver este complemento de instalación ‘Pipeline Utility Steps’ que nos proporciona el método readProperties (para referencia, vaya al enlace https://jenkins.io/doc/pipeline/steps/pipeline-utility-steps/#pipeline-utility- pasos) Aquí en el ejemplo podemos ver que están almacenando las claves en una matriz y usando las claves para recuperar el valor. Pero en ese caso, en producción, el problema será como si agregamos cualquier variable más adelante en el archivo de propiedades, esa variable también debe agregarse a la matriz del archivo Jenkins. Para deshacernos de este acoplamiento estrecho, podemos escribir código de tal manera que el entorno de compilación de Jenkins pueda obtener información automáticamente sobre todas las claves existentes que se presentan actualmente en el archivo de propiedades. Aquí hay un ejemplo de referencia.
def loadEnvironmentVariables(path){
def props = readProperties file: path
keys= props.keySet()
for(key in keys) {
value = props["${key}"]
env."${key}" = "${value}"
}
}
Y el código del cliente se parece a
path="\ABS_Output\EnvVars\pic_env_vars.properties"
loadEnvironmentVariables(path)