Activar construcciones de tuberías específicas para monorepos en Jenkins

Estoy en el proceso de convertir múltiples repositorios en un único repositorio, nuestra herramienta de CI elegida es Jenkins debido a la conversión de múltiples estructuras de repositorio en una sola. Han surgido 2 problemas principales.

1. Los tiempos de compilación / prueba han aumentado significativamente ya que todas las compilaciones / pruebas tienen que ejecutarse para cada confirmación individual. Esto se alivia parcialmente mediante el uso de una herramienta de compilación, en nuestro caso hemos optado por usar Buck.

2. Después de ejecutar todas las pruebas asociadas con el código comprometido, tengo un archivo Jenkins de implementación para cada proyecto. ¿Cómo podré activar solo los Jenkinsfiles para proyectos que necesiten volver a implementarse? Y si puedo hacerlo, ¿ es esta una práctica correcta ?

1. Obtenga una lista de archivos modificados y úsela para determinar qué pruebas ejecutar.

2. Cargue scripts Groovy externos en tiempo de ejecución para ejecutar sus implementaciones.

Puede usar el bloque " cuándo " combinado con la condición incorporada "conjunto de cambios" para ejecutar condicionalmente solo ciertas etapas de la tubería de su monorepo. De la documentación de when.changeset:

conjunto de cambios: ejecuta la etapa si el conjunto de cambios SCM de la compilación contiene uno o más archivos que coinciden con la cadena o glob dado. Ejemplo: cuando {changeset "** / *. Js"}

Aquí hay un ejemplo de Jenkinsfile usando esta estrategia:

pipeline {
    agent any
    stages {
        stage('build matchengine') {
            when {
                changeset "**/matchengine/*.*"
            }
            steps {
                echo 'building match engine'
            }
        }
        stage('build posttrade') {
            when {
                changeset "**/posttrade/*.*"
            }
            steps {
                echo 'building post trade'
            }
        }
    }
}

, aplicable a la estructura del proyecto monorepo que se muestra a continuación:

 .(my-project)
   |-- Jenkinsfile
   |-- matchengine
   |-- posttrade
   |-- serverless
   |-- ui

Esta estrategia no escalará más allá de las pequeñas bases de código porque sería difícil hacer un seguimiento de qué módulos dependen uno del otro. Sería mejor usar un sistema de compilación como Bazel. Su trabajo de CI simplemente emitiría una compilación de Bazel // ... (compila todo), y Bazel calcularía lo que realmente debe construirse y lo que debe probarse. Además, incluso existen reglas de bazel, como rules_docker y rules_k8s, que pueden calcular cuáles de sus contenedores deben reconstruirse y enviarse a un registro de contenedores, y cuáles de sus aplicaciones deben volver a implementarse en Kubernetes.