Jenkins: ¿pasar variables entre trabajos?


87

Tengo dos trabajos en jenkins, y ambos necesitan el mismo parámetro.

¿Cómo puedo ejecutar el primer trabajo con un parámetro para que cuando active el segundo trabajo, se use el mismo parámetro?


Podemos usar muchas formas: una mejor manera es usar los parámetros de trabajo actuales, o usar parámetros predefinidos en el trabajo de disparo descendente
ksr

1
Este título es tan confuso. ¿Cómo es esto de "pasar variables entre trabajos?". La respuesta también aceptada es un complemento. ¡De lujo que!
Rakib

Respuestas:


73

Puede utilizar el complemento de disparador parametrizado que le permitirá pasar parámetros de una tarea a otra.

También necesita agregar este parámetro que pasó de aguas arriba en aguas abajo.


10
Hola, lo siento por sonar como un novato, pero ¿está bien si alguien puede editar esto con detalles sobre cómo hacerlo con el complemento de disparador parametrizado?
Fadi

10
Nota al margen: No parece que las variables de entorno exportadas creadas en las secciones del script bash sean elegibles para sustitución en los parámetros de salida (por ejemplo, 'export VERSION' no hará que 'UPSTREAM_VERSION = $ VERSION' tome el valor correcto; solo obtiene '$ VERSION' en su lugar).
Mark McKenna

21
Esta respuesta es insuficiente
tarabyte

6
Estoy de acuerdo en que debería haber algún tipo de ejemplo de cómo pasar los parámetros al trabajo de destino. La página actual del Complemento de disparador parametrizado no ofrece buena información sobre esto. Podría haber, por ejemplo, qué tipo de sintaxis debería utilizar al pasar los parámetros.
skrii

2
El complemento ya no parece funcionar. Consulte la larga lista de problemas abiertos . Ya no puedo pasar ningún valor de parámetro con este complemento. ¿Alguna otra solución?
Markus L

38

1. Acciones posteriores a la compilación> Seleccione "Activar compilación parametrizada en otros proyectos"

Ingrese la variable de entorno con valor. El valor también puede ser Parámetros de compilación de Jenkins.

Los pasos detallados se pueden ver aquí: -

https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

Espero que sea útil :)


Esta respuesta satisface la pregunta que plantea OP sin requerir un complemento o usar DSL.
BTC

8
FYI, esta respuesta todavía necesita el complemento.
Thomas Lee

El complemento es excelente cuando, pero no puede pasar los valores de variable establecidos en las secciones de comando de ejecución de shell.
Tara Prasad Gurung

25

La respuesta aceptada aquí no funciona para mi caso de uso. Necesitaba poder crear parámetros dinámicamente en un trabajo y pasarlos a otro. Como menciona Mark McKenna, aparentemente no hay forma de exportar una variable desde un paso de compilación de shell a las acciones posteriores a la compilación.

Logré una solución alternativa usando el Complemento de disparador parametrizado escribiendo los valores en un archivo y usando ese archivo como los parámetros para importar a través de 'Agregar acción posterior a la compilación' -> 'Compilación parametrizada de gatillo ...' y luego seleccionando 'Agregar parámetros' - > 'Parámetros del archivo de propiedades'.


Esto es lo que necesitaba. Gracias.
luckytaxi

Si está dispuesto a usar la canalización jenkins 2.x, puede usar writeFile / stash-> unstash / readFile para copiar datos de estado entre trabajos. slideshare.net/ericlongtx/… Consulte la diapositiva 21 para ver un ejemplo.
siesta

Esto es necesario si desea que las variables SHELL pasen. Muy apreciado por esta respuesta.
Carl Wainwright

18

Creo que la respuesta anterior necesita una actualización:

Estaba tratando de crear un directorio dinámico para almacenar mis artefactos de compilación ascendentes, así que quería pasar el número de compilación de mi trabajo ascendente al trabajo descendente. Intenté los pasos anteriores pero no pude hacerlo funcionar. Así es como funcionó:

  1. Copié los artefactos de mi trabajo actual usando el complemento de copiar artefactos.
  2. En la acción posterior a la construcción del trabajo aguas arriba, agregué la variable como "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" y la configuré para activar el trabajo aguas abajo.
  3. Todo funcionó, excepto que mi trabajo posterior no pudo obtener $ SOURCE_BUILD_NUMBER para crear el directorio.
  4. Entonces descubrí que para usar esta variable tengo que definir la misma variable en el trabajo de flujo descendente como una variable de parámetro como en esta imagen a continuación:

ingrese la descripción de la imagen aquí

Esto se debe a que la nueva versión de jenkins también requiere que defina la variable en el trabajo posterior. Espero que sea de ayuda.


Totalmente de acuerdo. Esta es una actualización obligatoria que completa al 100% la respuesta inicial.
CodeSlave

También probé las dos opciones más votadas, pero ninguna de ellas funcionó hasta agregar la configuración adicional descrita en el paso 4 anterior. No necesitaba tener habilitados los artefactos de copia para que funcionara.
Jeff Fol

10

(para compañeros de Google)

Si está construyendo una canalización seria con Build Flow Plugin , puede pasar parámetros entre trabajos con el DSL de la siguiente manera:

Suponiendo un parámetro de cadena disponible "CVS_TAG", para pasarlo a otros trabajos:

build("pipeline_begin", CVS_TAG: params['CVS_TAG'])
parallel (
   // will be scheduled in parallel.
   { build("pipeline_static_analysis", CVS_TAG: params['CVS_TAG']) },
   { build("pipeline_nonreg", CVS_TAG: params['CVS_TAG']) }
)
// will be triggered after previous jobs complete
build("pipeline_end", CVS_TAG: params['CVS_TAG'])

Sugerencia para mostrar variables / parámetros disponibles:

// output values
out.println '------------------------------------'
out.println 'Triggered Parameters Map:'
out.println params
out.println '------------------------------------'
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }
out.println '------------------------------------'

Build Flow Plugin está en desuso, los usuarios deben migrar a wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin
vhamon

7

Solo agregue mi respuesta además de la de Nigel Kirby, ya que aún no puedo comentar:

Para pasar un parámetro creado dinámicamente, también puede exportar la variable en el mosaico 'Ejecutar Shell' y luego pasarla a través de 'Desencadenar compilación parametrizada en otros proyectos' => 'Parámetros predefinidos "=> dar' YOUR_VAR = $ YOUR_VAR '. Mi equipo usa esta función para pasar la versión del paquete npm del trabajo de compilación a los trabajos de implementación

ACTUALIZACIÓN: lo anterior solo funciona para los parámetros inyectados de Jenkins, el parámetro creado desde el shell aún necesita usar el mismo método. p.ej. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties y pase ese archivo en sentido descendente


3

Enfrenté el mismo problema cuando tuve que pasar una versión pom a un trabajo posterior de Rundeck.

Lo que hice fue usar la inyección de parámetros a través de un archivo de propiedades como tal:

1) Crear propiedades en el archivo de propiedades a través de shell:

Construir acciones:

  • Ejecutar un script de shell
  • Inyectar variables de entorno

P.ej : definición de propiedades

2) Pasar propiedades definidas al trabajo posterior: Acciones posteriores a la construcción:

  • Activar compilación parametrizada en otro proyecto
  • Agregar parámetros: parámetros de compilación actuales
  • Agregar parámetros: parámetros predefinidos

P.ej : envío de propiedades

3) Entonces fue posible usar $ POM_VERSION como tal en el trabajo Rundeck posterior.

/! \ Jenkins Versión: 1.636

/! \ Por alguna razón, al crear la compilación activada, fue necesario agregar la opción 'Parámetros de compilación actuales' para pasar las propiedades.


EDITAR: Encontré un error en lo que escribí. En la definición de propiedades, debería haber sido: echo POM_VERSION = $ POM_VERSION> play.properties y no: echo $ POM_VERSION >> play.properties Lo siento.
Eli Mous

2

Al leer las respuestas, no veo otra opción que me guste, así que la ofreceré también. Me encanta la parametrización de trabajos, pero no siempre se adapta bien. Si tiene trabajos que no están directamente aguas abajo del primer trabajo sino más adelante en la canalización, realmente no desea parametrizar cada trabajo en la canalización para poder pasar los parámetros hasta el final. O si tiene una gran cantidad de parámetros utilizados por una variedad de otros trabajos (especialmente aquellos que no están necesariamente vinculados a un trabajo principal o maestro), nuevamente la parametrización no funciona.

En estos casos, prefiero enviar los valores a un archivo de propiedades y luego inyectarlos en cualquier trabajo que necesite usando el complemento EnvInject . Esto se puede hacer dinámicamente, que es otra forma de resolver el problema de otra respuesta anterior donde todavía se usaban trabajos parametrizados. Esta solución se adapta muy bien a muchos escenarios.



0

¡Me lo imaginé!

Con casi 2 horas de prueba y error, lo descubrí.

Esto FUNCIONA y es lo que debe hacer para pasar variables al trabajo remoto:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2=${env.param2}")

Utilice \ n para separar dos parámetros, sin espacios.

A diferencia de los parámetros: '' 'someparams' ''

usamos paramters: "someparams"

el "..." es lo que nos da los valores de las variables deseadas. (Estas son comillas dobles, no dos comillas simples)

los '' '...' '' o '...' no nos darán esos valores. (Tres comillas simples o solo comillas simples)

Todos los parámetros aquí se definen en el bloque de entorno {} al inicio de la canalización y se modifican en etapas> pasos> scripts donde sea necesario.

También probé y descubrí que cuando usas "..." no puedes usar algo como '' '... "..."' '' o "... '..'..." o cualquier combinación de eso...

El problema aquí es que cuando usa "..." en la sección de parámetros, no puede pasar un parámetro de cadena; por ejemplo, esto NO FUNCIONARÁ:

    def handle = triggerRemoteJob(remoteJenkinsName: 'remoteJenkins', job: 'RemoteJob' paramters: "param1=${env.PARAM1}\nparam2='param2'")

si desea pasar algo como el anterior, deberá establecer una variable de entorno param2 = 'param2' y luego usar $ {env.param2} en la sección de parámetros del paso del complemento de activación remota

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.