2012-08-16 5 views
11

Estoy usando Jenkins para crear una canalización de compilación, y necesito activar un paso de implementación en la tubería. Esto significa un proceso manual (la construcción se produce automáticamente, cronometrada, luego se detiene en la etapa de implementación, esperando la autorización manual).¿Cómo puedo encadenar un trabajo descendente activado manualmente, también pasando parámetros?

necesito el paso a implementar también puede activarse con los parámetros procedentes de la etapa anterior.

Así, a través del 'plug-in parametrizado' me puede pasar parámetros entre puestos de trabajo. Puedo desencadenar trabajos descendentes automatizados O manualmente desencadenados (no estoy seguro si esta es una función estándar, o compilaciones manuales añadidas por algún complemento).

Sin embargo,, no encuentro ninguna forma de desencadenar un trabajo parametrizado manualmente.

¿Alguien sabe de una manera de hacer esto? ¿Hay otro complemento que pueda usar?

La razón que necesito los parámetros es que he creado un trabajo de implementación genérica, y la necesidad de pasar el nombre del módulo y la versión del experto de implementar. I podría crear trabajos de implementación específicos para cada módulo, pero esto sería muy doloroso.

también han estado considerando la siguiente, pero parece una chapuza:

  1. trabajo automatizado realiza la construcción, despliegue 'gatillo' disparadores construir, paso de parámetros.
  2. 'Despliegue disparador' escribe estos parámetros en un archivo en el sistema de archivos (build paso - ejecución del shell), y de forma manual desencadena la real trabajo de implementación
  3. trabajo de distribución (debe utilizar el espacio de trabajo desde el trabajo 'disparador despliegue') lee parámetros del sistema de archivos (usando el plugin EnvInject).

Hay varios problemas con este enfoque

  1. Es sólo que no me gusta.
  2. tiene un empleo intermedios acaba de pasar parámetros. Este estorba el espacio de trabajo Jenkins
  3. Como se construye se llevan a cabo en el mismo espacio de trabajo, parece frágil para mí (! Aunque viable)
+0

¿alguna vez llegar a una solución aceptable para esto? – Niklas

+0

No. Al final activé automáticamente un trabajo intermedio, pasando parámetros a esto. Esto establece el entorno vars en un archivo en el espacio de trabajo FS. Luego activé un paso manual para ejecutar otro trabajo en el _jun_ ambiente, que configura un entorno basado en el archivo de entorno establecido previamente. Hacky. – GKelly

+0

Acabo de utilizar un script para hacer eco de myparameter = $ POM_VERSION >> version.properties en un paso posterior de la compilación. Luego usó EnvInject para leer en version.properties en la siguiente compilación. –

Respuesta

6

La versión de producción actual (1.4.2) de build-pipeline-plugin le permite: especificar el trabajo manual en sentido descendente con parámetros, que se muestra en la tubería y se puede iniciar desde allí. Las versiones antiguas no podían hacerlo.

+0

No lo he probado aún (y me he mudado del proyecto), pero confiaría en este complemento. – GKelly

+1

Todavía no puedo hacer que esto funcione. Al igual que el OP, puedo hacerlo de forma automática y funciona muy bien, pero el manual no. –

+0

Tuve un problema donde las ejecuciones automáticas dominaban las ejecuciones manuales. Resulta que los trabajos se configuraron para compilarse cuando se ejecutó otro trabajo en lugar de depender únicamente del desencadenador manual ofrecido por el plugin build-pipeline. – J0hnG4lt

2

Echa un vistazo a la secuencia de los conectores Build: https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin.

Puede especificar puestos de trabajo, que se activará de forma automática o manualmente disparado.

También si usted necesita el paso de parámetros entre los puestos de trabajo que tendrá que descargar el maravilloso Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Groovy+plugin

Con el fin de pasar parámetros digamos una revisión al SVN entre puestos de trabajo que tendrá que Ejecutar Sistema maravilloso guión al comienzo de tu construcción. Este es un ejemplo que agregará un parámetro SVN_UPSTREAM que puede ser utilizado por cualquier trabajo en sentido descendente.NOTA: He notado un problema al crear un trabajo en sentido descendente que también tiene una secuencia de comandos groovy del sistema. Parece soplar cualquier referencia a los parámetros originales creados.

import hudson.model.* 
def build = Thread.currentThread().executable; 
build.addAction(new ParametersAction(new StringParameterValue("SVN_UPSTREAM", build.getEnvVars()['SVN_REVISION']))); 
println "SVN_UPSTREAM:" + build.getEnvVars()['SVN_UPSTREAM']; 
+0

El problema es que las configuraciones que necesito establecer para los trabajos posteriores se basan en cosas generadas durante la compilación (por ejemplo, paso el número de versión de los artefactos construidos, que se basa en el número de compilación de jenkins y un cálculo valor [versión de maven, menos '-SNAPSHOT]'). Hasta donde yo sé, las secuencias de comandos del sistema solo se pueden ejecutar al inicio de un trabajo. – GKelly

+0

He intentado varios complementos; build-pipeline-plugin, build-flow-plugin, parameterized-trigger-plugin. El problema es que ninguno de ellos parece ofrecer esta funcionalidad. [El plugin build-flow se ve prometedor, pero no he estado al día con su desarrollo. Puede que ofrezca esta funcionalidad ahora, no lo sé. Sin embargo, no menciona nada similar en la página wiki]. – GKelly

+0

Se ve correcto en el trabajo de subida utilizando la secuencia de comandos groovy, pero no se aprobó en sentido descendente para mí. – MikePatel

1

la acumulación secuencia de los conectores puede hacer esto, pero en el momento de escribir estas líneas, no en cualquier versión de lanzamiento. Construí el complemento desde main (rev 392 en ese momento), que incluye el patch mencionado en this issue y funciona para mí.
Cuando lo tiene instalado, puede usar una acción posterior a la construcción llamada "Crear otros proyectos (paso manual)" en el primer trabajo y allí puede configurar los parámetros para pasar a la segunda tubería (activada manualmente) trabajo.

+0

Esto es prometedor, pero parece no funcionar por desgracia.Puedo hacer que el trabajo en sentido descendente funcione con el trabajo de parámetros automáticos, pero no en el manual. –

2

Hay una especie de solución:

  • configuración manual de la promoción (Promover construye cuando ...> Sólo cuando sea aprobado manualmente) en el trabajo aguas arriba
  • en la promoción especificar añadir acciones> Gatillo acumulación parametrizado en otros proyectos, especifique el trabajo y agregue los parámetros

Una vez que promocione manualmente una construcción específica de trabajo en sentido ascendente, se iniciará una construcción de trabajo en sentido descendente. Pero el trabajo indirecto no aparecerá en la tubería.

+0

Esta es una solución aceptable para pasar los parámetros a un trabajo desencadenado manualmente. Desafortunadamente, en mi caso, mi trabajo desencadenado manualmente también necesita un parámetro ingresado manualmente, que no se detiene y solicita en esta solución. –

0

En mi opinión, no hay posibilidad de lograr el objetivo

Al iniciar los ductos cheques de entrega-tubería-plugin sólo los parámetros de primer empleo -> y luego la pantalla (o no) la pantalla initParam

Pero cuando paso siguiente (por ejemplo, desplegar) es manual y requiere Paramaters continuación, la pantalla initParam se ignora mirada en cuestión https://issues.jenkins-ci.org/browse/JENKINS-32336

Cuestiones relacionadas