詹金斯下游参数化作业的汇总结果

本文介绍了詹金斯下游参数化作业的汇总结果的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个Jenkins Build作业，它使用Jenkins Parameterized Trigger Plugin触发了多个以测试名称为参数的Test作业.这样就可以在多个可以正常运行的执行器上启动许多测试构建.

I have a Jenkins Build job which triggers multiple Test jobs with the test name as a parameter using the Jenkins Parameterized Trigger Plugin. This kicks off a number of test builds on multiple executors which all run correctly.

我现在想使用汇总下游测试结果->自动汇总所有下游测试"来汇总结果.我在构建"作业中启用了此功能，并设置了指纹识别，以便将其识别为下游作业.在构建作业的lastBuild"页面中，我可以看到它们被识别为下游构建:

I now want to aggregate the results using 'Aggregate downstream test results->Automatically aggregate all downstream tests'. I have enabled this in the Build job and have set up fingerprinting so that these are recognised as downstream jobs. In the Build jobs lastBuild page I can see that they are recognised as downstream builds:

下游版本

测试#1-#3

当我单击汇总测试结果"时，它仅显示最新的这些(测试#3).如果该作业始终运行相同的测试，但我的全部运行我的测试套件的不同部分，则这可能是一个好习惯.

When I click on "Aggregated Test Results" however it only shows the latest of these (Test #3). This may be good behaviour if the job always runs the same tests but mine all run different parts of my test suite.

我是否可以通过某种方式来汇总所有相关的下游Test版本?

Is there some way I can get this to aggregate all of the relevant downstream Test builds?

其他: 如果您复制测试作业，则汇总的测试结果确实有效.这不是理想的选择，因为我有大量的测试套件.

Additional: Aggregated Test Results does work if you replicate the Test job. This is not ideal as I have a large number of test suites.

推荐答案

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

I'll outline the manual solution (as mentioned in the comments), and provide more details if you need them later:

让 P 是父级作业，而 D 是下游作业(您可以轻松地将方法扩展到多个下游作业).

Let P be the parent job and D be a downstream job (you can easily extend the approach to multiple downstream jobs).

P 的实例(内部版本)通过参数化触发器插件通过构建步骤(不是作为构建后步骤)，并等待 D 完成.与其他参数一起， P 传递给 D 一个参数-我们将其称为 PARENT_ID -基于 P 的版本的 BUILD_ID .

D 执行测试并将其归档为工件(以及jUnit报告-如果适用).

P 然后执行一个外部Python(或内部Groovy)脚本，该脚本通过 PARENT_ID 找到合适的 D 构建(您遍历构建的 D 并检查 PARENT_ID 参数的值).然后，脚本将工件从 D 复制到 P ，然后 P 发布它们.

An instance (build) of P invokes D via Parameterized Trigger Plugin via a build step (not as a post-build step) and waits for D's to finish. Along with other parameters, P passes to D a parameter - let's call it PARENT_ID - based on P's build's BUILD_ID.

D executes the tests and archives them as artifacts (along with jUnit reports - if applicable).

P then executes an external Python (or internal Groovy) script that finds the appropriate build of D via PARENT_ID (you iterate over builds of D and examine the value of PARENT_ID parameter). The script then copies the artifacts from D to P and P publishes them.

如果使用Python(这就是我的工作)，请使用 Python JenkinsAPI包装器.如果使用Groovy，请使用 Groovy插件并将脚本作为系统脚本运行.然后，您可以通过其 Java API 来访问Jenkins.

If using Python (that's what I do) - utilize Python JenkinsAPI wrapper. If using Groovy - utilize Groovy Plugin and run your script as system script. You then can access Jenkins via its Java API.