如何编写Jenkinsfile实现5个代码仓库的统一定义及差异化构建

嘿，这个需求在多仓库CI场景里太常见了！我来分享几个实战过的靠谱实现方法，既能统一管理公共逻辑，又能灵活适配每个仓库的差异化需求：

这是扩展性最强、维护成本最低的方案——把所有仓库通用的流程抽成共享库的公共函数，每个仓库只需要定义自己的差异化构建步骤即可。

步骤1：创建共享库，封装公共逻辑 #

在Jenkins里创建一个专门的共享库仓库，比如命名为jenkins-shared-lib，然后在vars/CommonPipeline.groovy里编写公共流水线逻辑：

def call(Map config) {
  // 公共步骤1：拉取代码（所有仓库都需要）
  checkout scm

  // 公共步骤2：通用代码质量检查（可通过配置开关控制）
  if (config.enableSonar == true) {
    sonarQubeScan()
  }

  // 执行当前仓库的差异化构建任务（由传入的闭包定义）
  config.buildSteps()

  // 公共步骤3：归档构建产物
  archiveArtifacts artifacts: config.archivePattern ?: '**/target/*.jar, **/dist/**', fingerprint: true

  // 公共步骤4：构建结果通知（比如企业微信、Slack）
  sendBuildNotification(currentBuild.result)
}

步骤2：每个仓库的Jenkinsfile极简实现 #

每个仓库只需要引入共享库，然后传入自己的差异化配置和构建步骤即可：
比如**仓库A（Maven项目）**的Jenkinsfile：

// 引入共享库（my-shared-library是你在Jenkins全局配置里的共享库名称）
@Library('my-shared-library') _

CommonPipeline(
  enableSonar: true,
  archivePattern: '**/target/*.jar',
  buildSteps: {
    // 仓库A专属构建逻辑
    sh 'mvn clean package -DskipTests'
    sh 'mvn deploy'
  }
)

再比如**仓库B（Node.js项目）**的Jenkinsfile：

@Library('my-shared-library') _

CommonPipeline(
  enableSonar: false,
  archivePattern: '**/dist/**',
  buildSteps: {
    // 仓库B专属构建逻辑
    sh 'npm install --registry=https://mirrors.tencent.com/npm/'
    sh 'npm run build'
    sh 'rsync -avz dist/ admin@cdn.example.com:/var/www/static/'
  }
)

这种方式的优势很明显：公共逻辑改一次共享库就全量生效，每个仓库的Jenkinsfile只关注自己的差异点，后期维护起来特别省心。

如果仓库数量不多、差异逻辑比较简单，不想折腾共享库，可以直接在一个Jenkinsfile里通过仓库名称做分支判断：

pipeline {
  agent any
  stages {
    stage('公共步骤：拉取代码') {
      steps {
        checkout scm
      }
    }

    stage('公共步骤：通用代码检查') {
      steps {
        sh 'echo "执行通用ESLint/PMD检查..."'
      }
    }

    stage('差异化构建') {
      steps {
        script {
          // 从SCM地址提取仓库名称
          def repoName = scm.userRemoteConfigs[0].url.split('/')[-1].replace('.git', '')
          
          // 根据仓库名称执行对应构建逻辑
          switch(repoName) {
            case 'repo-a':
              sh 'mvn clean package'
              break
            case 'repo-b':
              sh 'npm run build'
              break
            case 'repo-c':
              sh 'go build -o myapp main.go'
              break
            case 'repo-d':
              sh 'docker build -t my-image:${BUILD_NUMBER} .'
              break
            case 'repo-e':
              sh 'gradle assemble'
              break
            default:
              error "未知仓库：${repoName}，请更新流水线逻辑！"
          }
        }
      }
    }

    stage('公共步骤：归档产物') {
      steps {
        archiveArtifacts artifacts: '**/target/*.jar, **/dist/**, myapp', allowEmptyArchive: true
      }
    }
  }
}

这种方式的好处是不需要额外维护共享库，直接一个Jenkinsfile搞定，但如果仓库数量增加或者差异逻辑变复杂，这个文件会变得臃肿，后期维护成本会上升。

如果希望非开发人员也能修改构建配置，可以让每个仓库根目录放一个ci-config.yaml配置文件，然后通过共享库读取配置并执行对应逻辑：

步骤1：仓库根目录添加配置文件 #

比如仓库C的ci-config.yaml：

enableSonar: true
archivePattern: '**/myapp'
buildCommands:
  - 'go mod download'
  - 'go build -o myapp main.go'
  - 'chmod +x myapp'

步骤2：共享库或Jenkinsfile读取配置并执行 #

@Library('my-shared-library') _

// 读取当前仓库的配置文件
def ciConfig = readYaml file: 'ci-config.yaml'

pipeline {
  agent any
  stages {
    stage('公共步骤：拉取代码') { steps { checkout scm } }

    stage('公共步骤：代码检查') {
      when { expression { ciConfig.enableSonar } }
      steps { sonarQubeScan() }
    }

    stage('差异化构建') {
      steps {
        script {
          ciConfig.buildCommands.each { cmd ->
            sh cmd
          }
        }
      }
    }

    stage('公共步骤：归档产物') {
      steps {
        archiveArtifacts artifacts: ciConfig.archivePattern, fingerprint: true
      }
    }
  }
}

这种方式把构建逻辑从代码里抽成配置文件，灵活性很高，适合需要频繁调整构建步骤的场景。

• 用共享库的时候，记得在Jenkins全局配置里绑定共享库，最好指定固定分支或tag，避免共享库的不稳定代码影响所有流水线
• 条件判断方式要注意仓库名称的准确性，比如SCM地址可能有HTTPS/SSH两种格式，提取名称的时候要兼容
• 配置文件驱动的方式可以加个默认配置 fallback，避免某个仓库忘记加配置文件导致流水线失败

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