如何配置可适配多个代码仓库的通用Jenkinsfile？

前置依赖确认 #

你需要先确保Jenkins已经安装以下插件：

• Pipeline
• Pipeline Utility Steps（用于读取yaml配置）
• Git
• 所有构建任务用到的其他依赖插件（比如容器构建、代码扫描相关插件）

具体实现步骤 #

1. 通用Jenkinsfile托管 #

建议将通用Jenkinsfile单独存放在一个独立的公共代码仓库进行版本管控，不要直接写死在Jenkins节点本地，方便后续迭代更新，路径示例：common-jenkins/Jenkinsfile

2. Jenkins任务批量配置 #

• 批量修改所有仓库对应的Jenkins任务配置，将「Pipeline source from SCM」的目标仓库改为公共通用Jenkinsfile仓库，Script Path填写通用Jenkinsfile的实际路径
• 保留原任务的Git触发规则、分支过滤规则，确保各仓库的代码提交、合并请求事件能正常触发对应构建任务

3. 业务仓库配置规范 #

所有业务仓库删除原有Jenkinsfile后，新增根路径下的config.yaml，配置示例如下：

# 项目基础信息
project:
  name: "user-service"
  lang: "go1.19"
  owner: "backend-team"
# 构建配置
build:
  enable: true
  command: "go mod tidy && go build -o main main.go"
# 镜像配置
image:
  enable: true
  registry: "harbor.example.com"
  repo: "backend/user-service"
  dockerfile_path: "./Dockerfile"
# 部署配置
deploy:
  enable: true
  env:
    - "test"
    - "prod"
  deploy_strategy: "rolling"
# 分支规则
branch_rule:
  main: "deploy to prod"
  develop: "deploy to test"
  feature/*: "only build no deploy"

4. 通用Jenkinsfile逻辑实现 #

核心逻辑是先拉取当前触发构建的业务仓库代码，读取其中的config.yaml，再根据配置内容决定要执行的构建阶段，示例代码如下：

pipeline {
  agent any
  environment {
    // 全局通用配置，可根据实际情况调整
    HARBOR_CRED = credentials('harbor-admin')
    K8S_CONFIG = credentials('k8s-kubeconfig')
  }
  stages {
    stage('拉取业务仓库代码') {
      steps {
        // 拉取触发构建的对应业务仓库的对应分支代码
        git url: "${GIT_URL}", branch: "${BRANCH_NAME}", credentialsId: 'git-global-cred'
      }
    }
    stage('加载业务仓库配置') {
      steps {
        script {
          // 读取config.yaml，转成groovy对象
          projectConfig = readYaml file: 'config.yaml'
          // 基础配置校验，避免配置缺失导致构建异常
          if (!projectConfig?.project?.name) {
            error "业务仓库config.yaml缺失project.name配置，构建终止"
          }
        }
      }
    }
    stage('代码构建') {
      when {
        expression { return projectConfig.build.enable == true }
      }
      steps {
        sh "${projectConfig.build.command}"
      }
    }
    stage('镜像构建推送') {
      when {
        expression { return projectConfig.image.enable == true }
      }
      steps {
        sh """
          docker build -f ${projectConfig.image.dockerfile_path} -t ${projectConfig.image.registry}/${projectConfig.image.repo}:${BUILD_NUMBER} .
          docker login ${projectConfig.image.registry} -u ${HARBOR_CRED_USR} -p ${HARBOR_CRED_PSW}
          docker push ${projectConfig.image.registry}/${projectConfig.image.repo}:${BUILD_NUMBER}
        """
      }
    }
    stage('部署到对应环境') {
      when {
        allOf {
          expression { return projectConfig.deploy.enable == true }
          // 匹配分支规则判断是否需要部署
          expression {
            if (BRANCH_NAME == 'main' && 'prod' in projectConfig.deploy.env) return true
            if (BRANCH_NAME == 'develop' && 'test' in projectConfig.deploy.env) return true
            return false
          }
        }
      }
      steps {
        // 对应部署逻辑，根据实际情况调整
        sh "kubectl --kubeconfig ${K8S_CONFIG} set image deployment/${projectConfig.project.name} ${projectConfig.project.name}=${projectConfig.image.registry}/${projectConfig.image.repo}:${BUILD_NUMBER}"
      }
    }
  }
  post {
    always {
      // 通用后置逻辑，比如清理镜像、发送构建通知等
      sh "docker system prune -f"
    }
    failure {
      // 通用失败通知逻辑，可在config.yaml配置通知接收人实现差异化
      sh "echo 构建失败，通知项目负责人: ${projectConfig.project.owner}"
    }
  }
}

注意事项 #

• 通用Jenkinsfile迭代更新前要做好兼容性测试，避免修改影响存量业务仓库的构建
• 可以在配置加载阶段增加schema校验，提前拦截不符合规范的config.yaml配置
• 如需支持更复杂的差异化逻辑，可以在通用Jenkinsfile中预留扩展点，允许业务仓库配置自定义脚本路径，通用流程执行到对应阶段自动调用自定义脚本

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