Jenkins y Bitbucket; cancelar la compilación anterior si se realiza una nueva confirmación en la misma rama?

Tenemos Jenkins ejecutando pruebas unitarias cuando se realizan confirmaciones a nuestro repositorio en Bitbucket. Esto está controlado por el complemento de Bitbucket, es decir, a través de un webhook de Bitbucket.

Actualmente, si se realiza una confirmación en la Rama A, se inicia una prueba unitaria. Si mientras se ejecuta ese trabajo se realiza una segunda confirmación en la Rama A, se iniciará una segunda prueba unitaria, por lo que ahora hay dos pruebas unitarias en la misma rama pero con un código ligeramente diferente.

Nuestro comportamiento preferido es que la primera prueba de confirmación se suspendería cuando se inicie la segunda prueba, de modo que solo se ejecute la prueba de unidad más reciente. ¿Se puede lograr esto?

Para aclarar; Tenemos muchas ramas, por lo que no podemos evitar las compilaciones concurrentes, cancelar la última tan pronto como comience la próxima, etc. Cualquier método que se use debe verificar específicamente si la rama ya tiene un trabajo en ejecución, no si el trabajo en general ya está corriendo.

He visto algunos controles de activación para Git, pero no Bitbucket. También encontré un script para verificar si el trabajo ya se está ejecutando y cancelarlo si es así, pero como se mencionó anteriormente, eso no se adapta a nuestro caso de uso. ¿Me estoy perdiendo de algo?

Nota: esta respuesta proviene de mi experiencia en la creación de soluciones personalizadas, no es solo de configuración, lo que, si está disponible, obviamente sería preferible. Pero tal vez sea algo a considerar de otra manera.

Puede enseñarle al script que ejecuta el trabajo de prueba de la unidad para que persista un estado de ejecución por rama.

Cuando se inicia el script, necesitaría obtener el nombre de la rama de sus parámetros de invocación. Entonces obtendría el estado persistente para la rama.

Si falta el estado o not runninglo configuraría running + job ID, ejecute la prueba unitaria y luego configure el estado en not running(o elimínelo).

Si el estado es running + job ID, significa que ya se está ejecutando otra prueba unitaria y usted tiene el ID de trabajo correspondiente. El script puede entonces (¿con gracia?) Terminar el trabajo que ya se está ejecutando por su ID y tomar su lugar, actualizando el estado a running + new job ID.

Pero, en mi humilde opinión, terminar un trabajo en progreso (que puede estar muy cerca de completarse) no es ideal: deja espacio para matar constantemente trabajos y lanzar nuevos solo para ser, a su vez, asesinados por trabajos posteriores, todo sin completar realmente ninguno. de ellos.

En cambio, modificaría la lógica para:

• deje el trabajo en progreso solo y, en su lugar, simplemente grabe en el estado persistente a pending job ID(ya sea un valor único, sobrescrito para reflejar el trabajo pendiente más reciente enviado o una lista de todos los trabajos pendientes, ordenados por tiempo de envío)
• cuando el trabajo en progreso se completa, verifica los pending job IDvalores y, si corresponde, inicia el más reciente (o el más antiguo, o incluso sigue alguna otra lógica de selección, si usa una lista)

Este enfoque evita el desperdicio de recursos de prueba unitaria y puede ajustarse fácilmente incluso para más de uno pero recursos aún limitados.