Jenkins Pipeline多仓库CI配置：实现变更触发统一构建

Hey there! Let's work through this problem you're having with your multi-repo Jenkins Pipeline. It makes total sense to want to skip unnecessary build stages when there's no actual code change—wasting resources on empty runs is never fun. Here are a few practical solutions tailored to your scenario:

1. Use the changeset Condition (Simplest Approach) #

Jenkins Pipeline has a built-in when directive that pairs perfectly with changeset() to check for code modifications. If you're checking out repos into separate directories (like your ABC dir), you can target changes specifically in that path to trigger the corresponding build stage.

Here's how to update your Pipeline:

pipeline{ 
  agent any 
  triggers { pollSCM('H/1 * * * *') } 
  stages { 
    stage('Checkout ABC') { 
      steps { 
        dir('ABC'){
          checkout poll: true, scm: [$class: 'GitSCM', branches: [[name: '**']], userRemoteConfigs: [[url: 'your-abc-repo-url']]]
        }
      }
    }
    stage('Build ABC') {
      // Only run this stage if there are changes in the ABC directory
      when {
        changeset pattern: '**/*', comparator: 'REGEXP', path: 'ABC/'
      }
      steps {
        dir('ABC') {
          // Your build commands here (e.g., `mvn clean install`, `npm run build`)
        }
      }
    }
    // Repeat for other repos (XYZ, DEF, etc.)
    stage('Checkout XYZ') {
      steps {
        dir('XYZ'){
          checkout poll: true, scm: [$class: 'GitSCM', branches: [[name: '**']], userRemoteConfigs: [[url: 'your-xyz-repo-url']]]
        }
      }
    }
    stage('Build XYZ') {
      when {
        changeset pattern: '**/*', comparator: 'REGEXP', path: 'XYZ/'
      }
      steps {
        dir('XYZ') {
          // Your shared build steps here
        }
      }
    }
  }
}

You can even refine the pattern to target specific file types (e.g., src/**/*.java) if you want to ignore changes to docs or config files that don't require a rebuild.

2. Manually Track Change Status (For Complex Multi-Repo Flows) #

If you need more control over change detection (like comparing specific commits or handling edge cases), you can capture the change status in an environment variable during checkout, then use that variable to gate your build stages.

Example implementation:

pipeline {
  agent any
  triggers { pollSCM('H/1 * * * *') }
  // Initialize environment variables to track changes per repo
  environment {
    ABC_CHANGED = 'false'
    XYZ_CHANGED = 'false'
  }
  stages {
    stage('Checkout ABC') {
      steps {
        dir('ABC') {
          checkout poll: true, scm: [$class: 'GitSCM', branches: [[name: '**']], userRemoteConfigs: [[url: 'your-abc-repo-url']]]
          script {
            // Compare current HEAD with the previous build's HEAD to detect changes
            def lastCommit = sh(script: 'git rev-parse HEAD^ 2>/dev/null || echo "initial-build"', returnStdout: true).trim()
            def currentCommit = sh(script: 'git rev-parse HEAD', returnStdout: true).trim()
            // Update the environment variable if changes exist
            ABC_CHANGED = (lastCommit != currentCommit) ? 'true' : 'false'
          }
        }
      }
    }
    stage('Build ABC') {
      when {
        expression { env.ABC_CHANGED == 'true' }
      }
      steps {
        dir('ABC') {
          // Your shared build steps
        }
      }
    }
    // Repeat the pattern for XYZ and other repos
  }
}

The 2>/dev/null || echo "initial-build" part handles the first run scenario where there's no previous commit to compare against.

3. Optimize Triggering with Webhooks (More Efficient Than Polling) #

While pollSCM works, using webhooks from your Git provider (GitHub, GitLab, etc.) is a better long-term solution. Webhooks trigger a Jenkins build only when code is pushed, eliminating unnecessary polling. Combine this with the changeset condition above, and you'll have a lean, efficient pipeline that only runs builds when needed.

Quick Notes to Keep in Mind: #

• If all repos share identical build steps, consider using Jenkins Shared Libraries to wrap those steps into a reusable function—this cuts down on duplicate code across your pipelines.
• Make sure your Jenkins agent has the necessary permissions to run git commands if you're using the manual change tracking method.

内容的提问来源于stack exchange，提问作者Jeffrey Devloo