2

我有一组工作，它们仅在他们构建的分支和其他一些属性上有所不同。这些作业有一个相当复杂的构建脚本，所以我想避免维护该脚本的多个副本。

避免冗余配置的一种可能方法是使用构建脚本设置一个主要作业，并使用与其他作业不同的参数来触发该作业。然而，这种方法有以下缺点：

  • 在分析一个特定参数集发生的问题时，从触发作业（从下游主作业继承其构建状态）到触发的主作业有一个额外的间接性。
  • 对于使用 git 子模块的项目，在主作业中检查不同的分支已被证明要么容易出错，要么非常昂贵。每个分支都有一个单独的工作区效果更好。

所以我的问题是：除了触发主作业之外，是否可以在触发作业中“内联”执行主作业？

例如，如果将主作业的控制台输出直接打印在触发作业的控制台中，那就太好了。此外，主作业应使用触发作业的工作区（或触发作业工作区的子文件夹中的工作区）。

4

2 回答 2

3

模板项目插件完全提供了我正在寻找的功能。

它提供了一个构建步骤“从另一个项目执行构建器”，它允许执行其他作业的构建步骤，因为它们在触发作业中被配置。

这太棒了：我现在可以从我的构建作业中“提取方法”（到新的“模板”作业中）并根据需要将它们组合在一起。

于 2013-07-24T14:42:23.080 回答
0

对于运行 500 多个构建作业的 Hudson 实例，我遇到了类似的可管理性问题——使用 gui 手动维护这么多作业是不切实际的。但是，您可以使用CLI以远程和编程方式在 Jenkins 和 Hudson 中配置作业- 它以 jar 文件的形式提供[https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI]。

我将它包装在 python 中并创建了一个 XML 文件来保存构建配置。这还提供了将 CI 实例“重置”回已知配置的能力 - 如果您怀疑构建失败是由 UI 中的手动更改引起的，或者您为部署到的每个环境使用不同的 CI 服务器（即 dev , test, prod) 并且需要提供一个新的。

如果您使用这种方法，您可以编写代码来生成 XML 文件并提供您的实例。我相信这是一种强大的方法，因为您还可以将 CI 配置保留在您的修订控制系统中。

尽管这不是一个简单的解决方案，但我无法找到或命名一个可以满足您要求的插件 - 这确实为您提供了编写一个的机会。

于 2013-07-24T10:14:03.383 回答