Modus

Jenkins-4-trigger

Implementación de Jenkins: Trigger por otro proyecto por detección de cambio de fichero

La potencia de Jenkins se apoya bastante en sus plugins que simplifican la programación. Pero algunos tienen limites. Es el caso de uno que se llama File Trigger que no funciona con pipelines.

En algunos casos, puede ser útil de disparar un job basado en existencia o propiedad de un fichero. De hecho es un tipo de trigger que ofrece el TAC.

Jenkins-file-trigger

La relación de Jenkins con el sistema de ficheros de la maquina huésped no permite acceder fuera del workspace. Por lo tanto, hay que recurrir al shell o powershell para capturar propiedades de ficheros.

 

Para simplificar la escritura del pipeline y poder usar de nuevo parte de código, aconsejamos de escribir los proyectos de detección de ficheros por separado y aprovechar los ajustes de disparo de los proyectos.

Se puede elegir de arrancar el build de un proyecto a partir del resultado de otro:

  • estable
  • inestable
  • fallo
jenkins4-build-trigger

Detección de fichero

Aquí ponemos ejemplo de pipeline para detección de presencia de un fichero. 

Primera etapa, llamada al sistema operativa mediante shell o powershell. Se almacena el path del fichero en una variable de entorno que solo será accesible desde este pipeline. El resultado del test de existencia del fichero se almacena en una variable EXISTE que se usará en el paso siguiente.

pipeline {

environment {
FILEX=«${USER_PATH}/Fichero.xlsx»
}
stages {

stage(‘Check Existe Ficheros‘) {

steps {

script {
if ( isUnix() ) {
EXISTE=false
try {
sh ‘test -f «$FILEX«‘
EXISTE=true
}
catch (Exception e) {}
} else {
powershell ‘Test-Path $env:FILEX -PathType leaf > Existe’
EXISTE_TEMP=readFile ‘Existe’
EXISTE=EXISTE_TEMP.replaceAll(«[^a-zA-Z ]+»,»»).toLowerCase().equalstrue«)
}

}

}

}

stage(‘Resultado Existe Ficheros‘) {

steps {

script {
echo («Resultado: » + EXISTE)
if ( EXISTE ) {} else
{
unstableNo existe el fichero vigilado
}
}
}
}

}

}

Este paso es muy sencillo, ajusta el estado del build del proyecto a inestable en caso de no estar presente el fichero.

En la vista de seguimiento del pipeline, vemos que cuando un build es inestable, el color del paso es amarillo mientras que cuando el build es estable aparece en verde.

En el ejemplo se ha detectado aparición del fichero vigilado en la ejecución #5

Cambios en ficheros

En este ejemplo nos interesa vigilar si un fichero ha cambiado por lectura de su propiedad de fecha de modificación (en plataforma Windows, la fecha de creación también). 

Se pueden poner el camino de acceso de varios ficheros como variable de entorno limitadas a éste pipeline:

pipeline {


environment {
FILE_1=»${USER_PATH}/Fichero1.xlsx«
FILE_2=»${USER_PATH}/Fichero2.xlsx«
FILE_3=»${USER_PATH}/Fichero3.xlsx«


}

Este proceso necesita recordar los valores de sus última ejecución para comparar los valores actuales.

Luego se usa la función de bash shell o powershell adecuada a la plataforma.

El resultado de las lectura se grava en forma de fichero en el workspace:

stages {


stage(‘Check Fechas Ficheros‘) {


steps {


// bat «set«
// sh «printenv«
script {
try {
if ( isUnix() ) {
sh ‘cat ultima_ejecucion > ultimo_chequeo
} else {
powershell ‘Copy-Item -Path ultima_ejecucion -Destination ultimo_chequeo
}
}
catch (Exception e) {}
if ( isUnix() ) {
sh »’
MAQ1=$(date -r «$FILE_1» «+%Y-%d-%m %H:%M:%S«)
echo $MAQ1 > ultima_ejecucion
MAQ2=$(date -r «$FILE_2» «+%Y-%d-%m %H:%M:%S»)
echo $MAQ2 >> ultima_ejecucion
MAQ3=$(date -r «$FILE_3» «+%Y-%d-%m %H:%M:%S«)
echo $MAQ3 >> ultima_ejecucion
»’
} else {
powershell »’
$MAQ1=(Get-Date -UFormat «%Y-%m-%d %H:%M:%S» (Get-Item $env:FILE_1).LastWriteTime)
echo $MAQ1 > ultima_ejecucion
$MAQ2=(Get-Date -UFormat «%Y-%m-%d %H:%M:%S» (Get-Item $env:FILE_2).LastWriteTime)
echo $MAQ2 >> ultima_ejecucion
$MAQ3=(Get-Date -UFormat «%Y-%m-%d %H:%M:%S» (Get-Item $env:FILE_3).CreationTime)
echo $MAQ3 >> ultima_ejecucion
»’
}


}

}

}

Se cargan en variables el contenido del fichero de fecha de la última ejecución y de la ejecución actual y se comparan.

Se ajusta el estado del build del proyecto a inestable en caso de tener diferencias:

 

stage(‘Cambios en Ficheros’) {

steps {


script {
UltC = readFile ‘ultimo_chequeo
echo UltC
UltE = readFile ‘ultima_ejecucion’
echo UltE
if ( UltC.equals(UltE) ) {
unstableNo cambios en los ficheros vigilados
} else {}
}
}
}


}


}

En la vista de seguimiento del pipeline, vemos que

la ejecución numero #1 resulta en fallo. Eso es porque no hay fichero de ejecución precedente para realizar la comparación.

La #2 nos devuelve un build inestable, con su paso de color amarillo porque se ejecutó a mano inmediatamente después con las mismas versiones de los ficheros vigilados.

En cambio el build #3 es estable aparece en verde porque la aplicación fuente ya había guardado una nueva versión de al menos uno de los ficheros.

 

Hemos llegado el final de nuestra presentación del abanico de posibilidades que tiene usar Jenkins como planificador.

En una primera parte vimos la arquitectura de la solución que hemos implementado.

En la segunda, repasamos los ajustes de Jenkins y los otros elementos necesarios para la solución.

La tercera, la hemos dedicado a detallar los pasos del script de tipo pileline desarrollado para ejecución de jobs de Talend con versionado de artefactos en repositorio Nexus.

Acabamos de ver como aprovechar la riqueza de Groovy añadido al shell del sistema operativo.

En función de los comentarios, podemos estudiar y desarrollar nuevos artículos.

Post relacionados