GitLabCE错误处理多个外部Jenkins作业的结果 - 一个或者不支持的错误？

Question

我希望在GitLabCE上复制一个我也成功使用GitHub的工作流程。我正在使用GitLabCE 8.11.5。

我让Jenkins通过webhook与GitLab-plugin合作完成每项工作。通常，当创建或更新合并请求时，挂钩会触发Jenkins作业，并且在允许审阅者完成合并之前，MR将等待完成该作业。

我想要实现的是此机制适用于多个并行和独立的Jenkins作业。例如，编译源的一个作业，一个用于在源上运行静态分析，另一个用于构建文档。我为它设置的方式，为每个作业使用单独的webhook配置，导致所有作业被正确触发，但是GitLab处理每个作业结果的方式存在问题，这可能（并且确实）导致过早合并。 / p>

实施例

根据GitLab的当前行为，审核人员不清楚后续结果可能正在等待，如此示例所示。过早合并可能是一种结果。

为简单起见，我在以下讨论中只有两个作业。作业并行运行，但第二个比第一个更快完成，当它向GitLab报告其状态时， GitLab将此视为第一个作业的“重试”，并错误地允许MR早期合并即可。当第二个作业完成时，结果将显示在MR的讨论中，但到那时MR可能已经合并。我期望看到的是GitLab等待两个作业完成，并且只有在两个成功后才允许合并。

MR Created

创建一个简单的MR。 GitLab发布了两个webhook，两个Jenkins作业并行运行。

但是“构建”选项卡仅显示一个条目。超链接指向第二个作业：

最快的工作完成

第二个（最快的）作业完成后，“构建”选项卡仅显示此项 - 此处没有迹象表明第一个（较慢的）作业仍在运行：

此外，合并按钮现在为绿色：

两个职位都完成

两个作业完成后，Builds选项卡现在显示：

正如您所看到的，第一个作业被标记为“重试”，但实际上这些超链接（＃335，＃336）现在指向单独的和正确的 Jenkins作业。然而，336显然不是335的“重试”。

此行为的顺序可能受我定义Web挂钩的顺序的影响。我没有进一步调查过这个问题。

结论

所以我的问题是 - GitLab是否支持多个独立的外部版本作为其MR流程的一部分？如果是这样，我如何修改配置，以便GitLab不会将第二个作业的结果视为第一个作业的结果？或者这是一个错误吗？

如果GitLab不支持多个外部版本（这很不幸，因为它在GitHub上工作得非常好），我或许可以使用Jenkins来触发所有并行作业，并在完成后报告最终状态。有谁知道这个工作流程的合适的Jenkins插件和配置？

披露

我已将此问题的变体发布到GitLab故障排除论坛。我将使用任何响应进行更新，以确保寻找类似解决方案的其他人保持一致。

Answer 1

回答我自己的问题：

我认为这种行为是由Jenkins中的GitLab插件配置引起的。每个作业都有一个＆＃34;发布构建状态到GitLab commit＆＃34;构建后的行动。这有一个名为＆＃34; Build name＆＃34;的字段，如果该字符串在管道中的所有构建中都不是唯一的，那么GitLab会感到困惑。通过将这些名称更改为唯一字符串，只有在所有作业都成功完成后，“合并”按钮才可用（前提是未投票）。

但是，我仍然只在Builds选项卡中看到一个条目，直到第一个作业成功完成，然后两个条目都出现（一个作为运行，一个作为传递）。第二个作业成功完成后，两者都显示为已通过。然而，这是次要的，不会影响审查或合并过程。