Jenkins多分支配置：如何基于可变字符串过滤分支？

嘿，我懂你现在的处境——7个面向不同目标平台的Jenkins多分支流水线，全都基于同一个Git仓库构建，但每个流水线的分支名称过滤器配置完全一致，每次要调整分支规则都得挨个修改这7个项目，维护起来太折腾了对吧？下面给你几个实用的优化方案，帮你摆脱重复配置的麻烦：

方案1：用Jenkins共享库统一管理分支过滤规则 #

把分支过滤的逻辑封装到共享库中，所有流水线共用同一套规则，后续改规则只需要动一处就行：

• 先创建Jenkins共享库，在库的vars目录下新建一个比如getFilteredBranches.groovy的文件，写入你的分支匹配规则：

def call() {
    // 这里写你之前用的wildcard规则，比如匹配release、feature、hotfix开头的分支
    return ['release/*', 'feature/*', 'hotfix/*']
}

• 接着在每个流水线的Jenkinsfile里引入这个共享库，用它来动态获取分支规则：

@Library('你的共享库名称') _

pipeline {
    agent any
    options {
        skipDefaultCheckout true
    }
    stages {
        stage('拉取代码') {
            steps {
                script {
                    def targetBranches = getFilteredBranches()
                    checkout scm: [
                        $class: 'GitSCM',
                        branches: targetBranches.collect { [name: it] },
                        userRemoteConfigs: [[url: '你的Git仓库地址']]
                    ]
                }
            }
        }
        // 这里放你对应目标平台的构建步骤
    }
}

• 以后要调整分支规则，只需要修改共享库中的代码，所有流水线都会自动应用新规则，不用再挨个改项目配置。

方案2：用全局环境变量统一分支过滤字符串 #

如果不想折腾共享库，也可以用Jenkins的全局属性来管理分支规则：

• 进入Jenkins的「系统管理」→「系统配置」，找到全局属性，添加一个环境变量，比如命名为BRANCH_FILTER_RULES，值填你之前用的wildcard字符串（比如release/*,feature/*）。
• 然后回到每个多分支流水线的配置页面，在Branch Sources -> Git -> Behaviors -> Filter by name (with wildcards)的输入框里，直接填${BRANCH_FILTER_RULES}。
• 要是遇到环境变量不生效的情况，可以安装EnvInject Plugin来增强Jenkins的环境变量引用能力。

方案3：合并流水线，用参数区分目标平台 #

如果这7个流水线的构建逻辑除了目标平台之外几乎一样，那更高效的方式是把它们合并成一个多分支流水线，用参数来指定构建的平台：

• 在流水线里添加一个选择型参数，比如叫TARGET_PLATFORM，选项就是你的7个平台名称。
• 然后在Jenkinsfile里根据这个参数执行对应平台的构建步骤：

pipeline {
    agent any
    parameters {
        choice(
            name: 'TARGET_PLATFORM',
            choices: ['platform1', 'platform2', 'platform3', 'platform4', 'platform5', 'platform6', 'platform7'],
            description: '选择要构建的目标平台'
        )
    }
    stages {
        stage('构建') {
            steps {
                script {
                    switch(TARGET_PLATFORM) {
                        case 'platform1':
                            sh './build-platform1.sh'
                            break
                        case 'platform2':
                            sh './build-platform2.sh'
                            break
                        // 依次添加其他平台的构建命令
                    }
                }
            }
        }
    }
}

• 这样一来，你只需要维护一个流水线项目，后续新增平台也只需要加个参数选项和对应的构建步骤就行，管理起来轻松太多。

小总结 #

如果只是想统一分支过滤规则，方案1或方案2都能满足需求；如果构建逻辑也高度相似，那方案3的合并流水线绝对是最优解，根据你的实际情况选就行~

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