如何程序化校验组织内Jenkins流水线均发布JUnit测试结果

方案可行性结论 #

存在可直接落地的程序化校验方案，且该方案兼容所有类型的Jenkins任务，不局限于Jenkinsfile定义的流水线。
你手动校验时判断页面是否存在「Test Results」模块的逻辑，本质是检查对应构建记录是否关联了JUnit插件生成的测试结果对象，这个判断逻辑可以完全通过Jenkins提供的原生接口实现，不需要依赖额外插件。

手动校验的页面参考：

核心实现逻辑 #

不要通过扫描任务配置（比如解析Jenkinsfile、读取自由风格项目的XML配置）判断是否配置了JUnit发布，这种方式漏判率极高：配置了junit步骤不代表实际执行成功，可能存在路径配置错误、测试步骤失败未走到发布逻辑、条件分支未触发等场景。
最准确的判断逻辑和人工校验完全对齐：

1. 先圈定你要校验的范围：可以是单个文件夹、视图、GitLab/GitHub组织级流水线根目录、甚至整个Jenkins实例
2. 递归遍历范围内的所有任务，跳过无历史构建记录的无效任务
3. 取每个任务最近的有效构建（如果担心单次构建偶发异常导致误判，可以扩展为检查最近3~5次构建），检查构建记录上是否挂载了hudson.tasks.junit.TestResultAction对象——这个对象就是JUnit插件发布测试结果后，在构建上留下的唯一标识，和页面上显示「Test Results」模块是一一对应的
4. 输出所有未挂载该对象的任务清单即可

可直接使用的实现脚本 #

你可以直接把下面的Groovy脚本粘贴到Jenkins 系统管理→脚本控制台里执行，就能拿到指定分组下的校验结果：

import hudson.tasks.junit.TestResultAction
import com.cloudbees.hudson.plugins.folder.Folder

// 替换为你要校验的目标分组/文件夹的全路径，校验整个Jenkins实例就填Jenkins.instance
def targetScope = Jenkins.instance.getItemByFullName("你的目标业务分组名")
def abnormalJobs = []
def validJobCount = 0

// 递归遍历分组下所有子分组、任务
def traverse
traverse = { itemGroup ->
    itemGroup.items.each { item ->
        // 遇到子文件夹就递归往下查
        if (item instanceof Folder) {
            traverse(item)
            return
        }
        def lastBuild = item.lastBuild
        if (!lastBuild) {
            abnormalJobs << "${item.fullName}：无历史构建记录，无法校验"
            return
        }
        validJobCount++
        // 检查是否存在JUnit测试结果对象
        def hasJunitResult = lastBuild.getAction(TestResultAction) != null
        if (!hasJunitResult) {
            abnormalJobs << "${item.fullName}：最近一次构建(#${lastBuild.number})未成功发布JUnit测试结果"
        }
    }
}

traverse(targetScope)

// 打印结果
println "=== 校验完成，共覆盖 ${validJobCount} 个有构建记录的有效任务 ==="
println "=== 异常任务清单 ==="
abnormalJobs.each { println "- ${it}" }

如果你不想用Groovy脚本，也可以用Python/Shell调用Jenkins REST API实现同样的逻辑：给每个构建的API地址拼接参数/api/json?tree=actions[_class]，检查返回的actions列表里是否存在hudson.tasks.junit.TestResultAction类即可。

兼容性说明 #

这个校验逻辑100%兼容所有Jenkins任务类型：

• 支持所有Jenkinsfile定义的流水线：包括声明式流水线、脚本式流水线、多分支流水线、组织级流水线
• 支持传统非流水线任务：包括自由风格软件项目、Maven项目、Gradle项目、其他第三方插件扩展的自定义任务类型
  只要任务是通过官方JUnit插件发布测试结果，就不会漏判。
  不管你是通过Jenkinsfile的junit步骤发布结果，还是在任务配置页手动关联JUnit报告路径，最终成功发布后都会在构建上挂载相同的TestResultAction对象，判断逻辑没有区别。

Jenkinsfile方式配置JUnit发布的参考示例：

pipeline {
    agent any

    stages {
        stage('Compile') {
            steps { 
                // Login to Repository
                configFileProvider([configFile(fileId: 'nexus_maven_configuration', variable: 'MAVEN_SETTINGS')]) {
                    sh 'mvn -s $MAVEN_SETTINGS compile'
                }
            }
        }

        stage('Test') { 
            steps { 
                configFileProvider([configFile(fileId: 'nexus_maven_configuration', variable: 'MAVEN_SETTINGS')]) {
                    sh 'mvn -s $MAVEN_SETTINGS test'
                }
            }
        }
    }
    post {
        always {
            junit '**/target/surefire-reports/*.xml'
            archive 'target/*.jar'
        }
    }
}

如果需要做定期巡检，可以把上述逻辑包装成定时任务，定期输出异常清单推送到告警渠道即可。

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