【问题标题】:Aggregating results of downstream parameterised jobs in Jenkins在 Jenkins 中聚合下游参数化作业的结果
【发布时间】:2012-05-10 12:56:52
【问题描述】:

我有一个 Jenkins 构建作业,它使用 Jenkins 参数化触发器插件触发多个测试作业,并将测试名称作为参数。这会在多个执行器上启动许多测试构建,这些执行器都运行正常。

我现在想使用“聚合下游测试结果->自动聚合所有下游测试”来聚合结果。我已在 Build 作业中启用此功能并设置了指纹识别,以便将它们识别为下游作业。在 Build jobs lastBuild 页面中,我可以看到它们被识别为下游构建:

下游构建

测试#1-#3

当我点击“聚合测试结果”时,它只显示最新的(测试#3)。如果作业总是运行相同的测试但我的所有测试都运行我的测试套件的不同部分,这可能是一种很好的行为。

有什么方法可以让我聚合所有相关的下游测试版本?

补充: 如果您复制测试作业,聚合测试结果确实有效。这并不理想,因为我有大量的测试套件。

【问题讨论】:

  • 我在汇总下游测试结果时遇到了很多麻烦,最终我自己“手动”汇总它们:等到下游作业完成并将测试报告复制到父级。
  • 已经让自动聚合工作(通过复制作业)我可以看到它并不是我所希望的(它不会合并测试层次结构或聚合图表)。对于参数化作业,我会接受手动完成的解决方案。

标签: jenkins


【解决方案1】:

我将概述手动解决方案(如 cmets 中所述),并在您以后需要时提供更多详细信息:

P 为父作业,D 为下游作业(您可以轻松地将方法扩展到多个下游作业)。

  1. P 的实例(构建)通过 Parameterized Trigger Plugin 通过构建步骤调用 D不是 作为构建后步骤)并等待 D 完成。与其他参数一起,P 传递给 D 一个参数 - 我们称之为 PARENT_ID - 基于 P 的构建的 BUILD_ID
  2. D 执行测试并将它们存档为工件(连同 jUnit 报告 - 如果适用)。
  3. P 然后执行一个外部 Python(或内部 Groovy)脚本,该脚本通过 PARENT_ID 找到 D 的适当构建(您迭代 D 并检查 PARENT_ID 参数的值)。然后该脚本将工件从 D 复制到 PP 发布它们。

如果使用 Python(我就是这样做的)- 请使用 Python JenkinsAPI wrapper。如果使用 Groovy - 利用 Groovy Plugin 并将您的脚本作为系统脚本运行。然后,您可以通过其Java API 访问 Jenkins。

【讨论】:

  • 该流程的问题是 P 尚未归档其工件。通常你会测试工件,所以你必须进一步分解它。
  • @malenkiy_scot 你说“通过 PARENT_ID 找到合适的 D 版本”。我不知道这到底是什么意思。 D 对 Parent_Id 做了什么,现在可以搜索它的内容?它是否将测试结果存档为 ZIP 文件,并且该 zip 文件名为 parent_id?
【解决方案2】:

我使用声明性管道提出了以下解决方案。

它需要安装“复制工件”插件。

在下游作业中,将“env”变量设置为结果文件的路径(或模式路径):

post {
  always {
    steps {
      script {
        // Rem: Must be BEFORE execution that may fail   
        env.RESULT_FILE='Devices\\resultsA.xml'
      }
      xunit([GoogleTest(
        pattern: env.RESULT_FILE,
      )])
    }
  }
}

请注意,我使用 xunit,但同样适用于 junit

在父作业中,保存构建变量,然后在后期处理中,我使用以下代码汇总结果:

def runs=[]

pipeline {
  agent any
  stages {
    stage('Tests') {
      parallel {
        stage('test A') {
          steps {
            script {
              runs << build(job: "test A", propagate: false)
            }
          }
        }
        stage('test B') {
          steps {
            script {
              runs << build(job: "test B", propagate: false)
            }
          }
        }
      }
    }
  }
  post {
    always {
      script {
        currentBuild.result = 'SUCCESS'
        def result_files = []
        runs.each {
          if (it.result != 'SUCCESS') {
            currentBuild.result = it.result
          }
          copyArtifacts(
            filter: it.buildVariables.RESULT_FILE,
            fingerprintArtifacts: true,
            projectName: it.getProjectName(),
            selector: specific(it.getNumber().toString())
          )
          result_files << it.buildVariables.RESULT_FILE
        }
        env.RESULT_FILE = result_files.join(',')
        println('Results aggregated from ' + env.RESULT_FILE)
      }
      archiveArtifacts env.RESULT_FILE
      xunit([GoogleTest(
        pattern: env.RESULT_FILE,
      )])
    }
  }
}

请注意,父作业还设置了“env”变量,因此它本身可以被父作业聚合。

【讨论】:

  • 这是我在互联网上找到的聚合下游 Jenkins 测试结果的一般问题的最优雅和有启发性的解决方案。荣誉。工件指纹识别是否必须严格执行?
  • @timblaku 聚合并不是绝对必要的。这只是为了方便识别文件,因为它们被复制到多个作业中。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-03-08
  • 2013-05-01
  • 1970-01-01
  • 2019-01-07
  • 1970-01-01
  • 2013-12-22
  • 1970-01-01
相关资源
最近更新 更多