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


11

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 ?


¿Cómo se implementan los ganchos de compilación? ¿Sondea el repositorio con Jenkins? ¿Tienes ganchos de git en cada confirmación?
PrestonM

Tenemos githooks en su lugar en cada commit
YellowPillow

Respuestas:



8

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.


Desafortunadamente, el conjunto de cambios no contiene todos los cambios de las solicitudes de cambio, solo delta entre las dos últimas confirmaciones. Sin embargo, la verificación personalizada se puede implementar fácilmente.
Kirtul
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.