Jenkins构建前如何检测仓库指定文件夹是否存在变更

以下是生产环境验证过的可落地方案，按适用场景排序：

方案1：原生Git命令检测（无插件依赖，兼容性最强） #

不需要安装任何额外Jenkins插件，直接在Pipeline内调用Git命令对比两次提交的差异路径，逻辑完全可控，适配所有Git类代码仓库，是稳定性最高的实现方式。
核心逻辑是取当前服务上次成功构建的commit哈希，和当前HEAD做diff，判断变更文件是否落在监控范围内，示例代码：

pipeline {
    agent any
    environment {
        // 每个服务Pipeline只需要修改这两个配置即可
        MONITOR_SERVICE_PATH = "services/order-service/"
        MONITOR_COMMON_PATH = "common/,config/,pom.xml"
    }
    stages {
        stage('变更检测') {
            steps {
                script {
                    // 拉取全量git历史，保证diff可以正常执行
                    sh 'git fetch --all --tags'
                    // 取上次成功构建的commitID，首次构建/无历史记录默认放行
                    def lastSuccessCommit = currentBuild.previousBuild?.getRawBuild()?.getActions(hudson.plugins.git.util.BuildData.class)
                        ?.find { it.lastBuild != null }?.lastBuild?.revision?.hash
                    if (!lastSuccessCommit) {
                        echo "无历史成功构建记录，执行全量构建"
                        env.BUILD_REQUIRED = "true"
                    } else {
                        // 输出两个commit之间所有变更的文件路径
                        def changedFileList = sh(
                            script: "git diff --name-only --diff-filter=ACMRT ${lastSuccessCommit} HEAD",
                            returnStdout: true
                        ).trim().split('\n').findAll { it.trim().length() > 0 }
                        // 校验是否有文件匹配监控路径
                        def monitorPaths = (env.MONITOR_SERVICE_PATH + "," + env.MONITOR_COMMON_PATH).split(",")
                        env.BUILD_REQUIRED = changedFileList.any { file ->
                            monitorPaths.any { path -> file.startsWith(path) }
                        } ? "true" : "false"
                    }

                    if (env.BUILD_REQUIRED != "true") {
                        echo "监控范围无有效变更，跳过后续构建流程"
                        currentBuild.result = 'SUCCESS'
                        return
                    }
                }
            }
        }
        // 原有构建、测试、部署逻辑放在后续阶段
        stage('构建部署') {
            when {
                environment name: 'BUILD_REQUIRED', value: 'true'
            }
            steps {
                echo "检测到有效变更，开始执行构建部署"
                // 写入原有构建逻辑即可
            }
        }
    }
}

这个方案支持自定义任意复杂规则，比如排除目录下README、.gitignore这类不影响构建的文件变更，只需要在路径判断逻辑里加过滤条件即可。

方案2：声明式Pipeline原生changeset条件（配置最简单） #

如果使用较新版本的Jenkins声明式Pipeline，可以直接用内置的changeset条件做路径匹配，不需要手写Git命令，配置量最小，适合服务数量少、Pipeline逻辑简单的场景，示例：

pipeline {
    agent any
    stages {
        stage('构建部署') {
            when {
                anyOf {
                    // 用通配符匹配服务目录下所有层级的文件变更
                    changeset "services/payment-service/**"
                    changeset "common/**"
                    changeset "pom.xml"
                    // 首次构建、分支新建、打标签场景默认放行
                    not { triggeredBy 'SCMTrigger' }
                    buildingTag()
                }
            }
            steps {
                echo "检测到匹配路径变更，执行构建流程"
                // 写入原有构建逻辑
            }
        }
    }
}

注意：这个方案默认只对比当前触发和上一次构建的变更集，如果上一次构建被跳过、执行失败，可能出现变更漏检，生产环境使用建议配合变更集持久化配置，或者直接选方案1的Git命令检测逻辑。

方案3：共享库封装逻辑（适合微服务数量多的团队） #

如果微服务数量超过10个，每个Pipeline重复写检测逻辑维护成本很高，可以把方案1的检测逻辑封装成Jenkins共享库的公共方法，所有服务Pipeline直接调用即可，示例调用方式：

// 引入团队内部的Jenkins共享库
@Library('devops-shared-lib') _
pipeline {
    agent any
    environment {
        SERVICE_PATH = "services/user-service/"
    }
    stages {
        stage('前置检测') {
            steps {
                script {
                    // 直接调用封装好的检测方法，传入监控路径即可返回是否需要构建
                    if (!monoRepoUtil.checkChanged(env.SERVICE_PATH, "common/", "build.gradle")) {
                        echo "无相关变更，跳过构建"
                        currentBuild.result = 'SUCCESS'
                        return
                    }
                }
            }
        }
        // 后续构建步骤
    }
}

落地注意事项 #

• 检测逻辑要放在Pipeline最靠前的位置，确认不需要构建直接结束，不要占用Jenkins执行器跑无用的代码拉取、依赖安装步骤
• 根目录的全局配置、公共依赖目录、基础Dockerfile这类被所有服务依赖的文件，一定要加入所有服务的监控范围，避免公共代码变更后服务没重新构建引发故障
• 可以通过--diff-filter=ACMRT参数过滤掉文件删除类的变更，减少不必要的构建触发
• 新建分支、首次构建、打标签的场景一定要默认放行，不要因为没有历史commit导致构建无法触发

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