Acionando compilações de pipeline específicas para monorepos em Jenkins

Estou no processo de conversão de vários repositórios em um único repositório. Nossa ferramenta de CI de escolha é o Jenkins devido à conversão de várias estruturas de repositório em um único problema.

1. Os tempos de construção / teste aumentaram significativamente, pois todas as construções / testes precisam ser executadas para cada confirmação única. Isso é parcialmente aliviado pelo uso de uma ferramenta de compilação; no nosso caso, continuamos usando Buck.

2. Depois que todos os testes associados ao código confirmado são executados, eu tenho um Jenkinsfile de implantação para cada projeto. Como poderei acionar apenas os arquivos Jenkins para projetos que precisam ser reimplantados? E se eu sou capaz de fazer isso, essa é uma prática correta ?

1. Obtenha uma lista de arquivos alterados e use-a para determinar quais testes executar.

2. Carregue scripts Groovy externos em tempo de execução para executar suas implantações.

Você pode usar o bloco " when " combinado com a condição "changeset" incorporada para executar condicionalmente apenas determinados estágios do pipeline do seu monorepo. Na documentação when.changeset:

changeset - Executa o estágio se o changeset do SCM da compilação contiver um ou mais arquivos correspondentes à string ou glob especificados. Exemplo: quando {changeset "** / *. Js"}

Aqui está um exemplo do Jenkinsfile usando esta estratégia:

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'
            }
        }
    }
}

, aplicável à estrutura do projeto monorepo mostrada abaixo:

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

Essa estratégia não ultrapassará pequenas bases de código, porque seria difícil acompanhar quais módulos dependem um do outro. Você estaria melhor usando um sistema de compilação como o Bazel. Seu trabalho de IC simplesmente emitia uma compilação do bazel // ... (compila tudo), e o Bazel calculava o que realmente precisa ser construído e o que precisa ser testado. Além disso, existem ainda regras do bazel, como rules_docker e rules_k8s, que podem calcular quais contêineres precisam ser reconstruídos e enviados a um registro de contêineres e quais aplicativos precisam ser reimplantados no Kubernetes.