构建 xunit.xml 文件后，我应该使用 xUnitPublisher 还是 xUnitBuilder？答案

【问题标题】：Should I use xUnitPublisher or xUnitBuilder after building xunit.xml files?构建 xunit.xml 文件后，我应该使用 xUnitPublisher 还是 xUnitBuilder？
【发布时间】：2017-01-02 08:53:58
【问题描述】：

我正在自动化 dot net core build

鉴于我的 Jenkins 文件中的以下 sn-p，我为我拥有的每个测试项目生成一个 XML 文件。在接下来的步骤中，我想处理这些 XML 文件。

Jenkins 提供了两种选择。我很困惑使用哪个选项。我使用“过程”还是“发布”。两者都给出了相同的阈值选项，两者似乎都做同样的事情。他们都将构建标记为 FAILED，他们都向 Jenkins 提供了测试报告。这是遗产吗？或者它们是完全不同的步骤，有自己的目的？

顺便说一句，这个 FAILURE 检查并抛出错误是阻止 Jenkins 继续构建的唯一方法吗？当构建标记为 FAILED 以继续其余步骤时，这似乎有点奇怪。如果我想继续，我也可以将 stopProcessingIfError 设置为 false，还是我错过了重点？

stage('Test') {
    def testScript = ""
    def testProjects = findFiles(glob: 'test/**/project.json')

    if (!fileExists('reports/xml')) {
        if (!fileExists('reports')) {
            sh "mkdir reports"
        }
        sh "mkdir reports/xml"
    }

    for(prj in testProjects) {
        println "Test project located, running tests: " + prj.path
        def matcher = prj.path =~ 'test\\/(.+)\\/project.json'

        testScript += "dotnet test --no-build '${prj.path}' -xml 'reports/xml/${matcher[0][1]}.Results.xml' || true\n"
    }

    sh testScript

    step([
        $class: 'XUnitBuilder',
        thresholdMode: 1,
        thresholds: [[$class: 'FailedThreshold', failureThreshold: '1']],
        tools: [[
            $class: 'XUnitDotNetTestType',
            deleteOutputFiles: true,
            failIfNotNew: true,
            pattern: 'reports/xml/*.Results.xml',
            skipNoTestFiles: false,
            stopProcessingIfError: true
        ]]
    ])

    if (currentBuild.result.equals("FAILURE")) {
        throw "Test results did not pass thresholds"
    }
}

【问题讨论】：

标签： .net jenkins asp.net-core continuous-integration

【解决方案1】：

查看源代码后，它们在功能上似乎相同，除了XUnitPublisher 多了一个方法，我不明白它的目的（！），并且该类在@987654327 中声明了更多接口@列表。

关键的区别似乎是XUnitPublisher 类扩展了hudson.tasks.Recorder 类，而XUnitBuilder 扩展了hudson.tasks.Builder。

我认为面向用户的区别在于，构建器中的失败将 Jenkins 作业标记为“失败”，而发布者中的失败将作业标记为“不稳定”。（来源：https://wiki.jenkins.io/display/JENKINS/Terminology）

鉴于这一切，我建议使用 xUnitPublisher。如果编译通过但某些测试失败，我将构建命令设置为返回 0。这样，Jenkins 给我一个失败的编译状态和一个不稳定的状态，用于工作编译但测试失败。我喜欢这样。

提交历史并没有解释为什么会出现这种荒谬的代码重复。我会理解一个是根据另一个来实现的，就像弃用时通常所做的那样……可能是因为每个都必须有不同的超类。

XUnitBuilder.java, XUnitPublisher.java

【讨论】：

【解决方案2】：

来自日志：警告：XUnitBuilder 步骤自 2.x 以来已弃用，它已被 XUnitPublisher 取代。此构建器将在版本 3.x 中删除所以答案是：使用 XUnitPublisher，如上面的答案 1 所述。

【讨论】：

【解决方案3】：

我设法使用这个简单的 groovy \ pipline + running unittests 来做到这一点

所以最终的管道是：

node {
stage 'Checkout'
    checkout scm

stage 'Build'
    bat "\"C:/Program Files/dotnet/dotnet.exe\" restore \"${workspace}/MyProg.sln\""
    bat "\"C:/Program Files/dotnet/dotnet.exe\" build \"${workspace}/MyProg.sln\""

stage 'UnitTests'
    bat returnStatus: true, script: "\"C:/Program Files/dotnet/dotnet.exe\" test \"${workspace}/MyProg.sln\" --logger \"trx;LogFileName=unit_tests.xml\" --no-build"
    step([$class: 'MSTestPublisher', testResultsFile:"**/unit_tests.xml", failOnError: true, keepLongStdio: true])
}

我已经上传了一些我自己做的例子到我的 GitHub 上供大家使用和贡献，欢迎大家看看：

https://github.com/avrum/JenkinsFileFor.NETCore

那些管道 jenkinsfile 会将此管道模板添加到您的构建中：

【讨论】：