changeset规则匹配但Jenkins对应stage未触发的问题求助

问题根因确认 #

是的，你使用skipDefaultCheckout()+阶段内自定义检出的配置，就是导致changeset规则不生效、Unit Test阶段未触发的直接原因。
Jenkins流水线内置的changeset匹配逻辑，依赖流水线初始化阶段默认检出操作生成的构建变更集数据。当你关闭默认检出后，Jenkins在执行when条件判断时，还没有拉取代码也没有生成对应变更记录，changeset规则拿不到匹配的文件列表，会直接判定为不满足条件，跳过对应阶段。

解决方案 #

方案1：基于Generic Webhook payload自定义匹配逻辑（推荐，多仓库场景更稳定） #

你使用Generic Webhook Plugin触发流水线，webhook的请求payload中本身就包含本次推送对应的所有新增/修改/删除文件列表：

1. 先在Generic Webhook Plugin的配置中，提取payload里的变更文件列表，存入流水线参数变量，比如命名为COMMIT_CHANGED_FILES
2. 替换原来的changeset规则，自己写表达式判断：

expression {
    def changedFiles = params.COMMIT_CHANGED_FILES.split(',')
    def pattern1 = ~/([a-zA-Z]*_cli|clarity_xml_tools)\/.*/
    def pattern2 = ~/jenkins\/pipeline_scripts\/.*/
    return changedFiles.any { it ==~ pattern1 || it ==~ pattern2 }
}

方案2：提前检出仓库并导入变更记录 #

如果要沿用内置changeset规则：

1. 在所有带when条件的stage之前，新增一个无触发条件的初始化阶段，完成两个仓库的检出操作
2. 给对应需要判断变更的仓库的checkout步骤添加参数changelog: true, poll: true，让Jenkins将本次检出的变更记录导入到构建的变更集中，后续changeset规则即可正常匹配。

注意：如果是多个仓库场景，内置changeset默认只会识别第一个配置的SCM的变更，存在匹配逻辑混淆的风险，多仓库场景更推荐使用方案1。

验证方法 #

你可以先新增一个无任何触发条件的测试stage，输出当前构建的变更集内容，确认是否为空即可验证根因：

stage("Test ChangeSet") {
    steps {
        echo "Current build change sets: ${currentBuild.changeSets}"
    }
}

如果输出为空，说明Jenkins确实没有获取到变更记录，和上述根因判断一致。

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