39

为什么 Jenkins 有两种工作，多配置项目和自由式项目项目？我在某处读到，一旦您选择其中一个，就无法（轻松地）转换为另一个。为什么我不总是选择多配置项目以确保未来更改的安全？

我想为在 Windows 和 Unix（以及其他平台）上构建的项目设置构建。我发现了这个问题），它问了同样的事情，但我并没有真正得到答案。为什么我需要三个矩阵项目（而不是三个自由样式项目），每个平台一个？为什么我不能将它们全部保存在一个矩阵中，一个轴上有平台和（例如）gcc 版本，另一个轴上有（我的）软件版本？

我也阅读了这篇博文，但它在同一台机器上构建了所​​有内容，只是使用了不同的 Python 版本。

所以，简而言之：大多数人如何配置针对许多不同平台的多配置项目？

4

9 回答 9

42

这两种类型的工作具有不同的功能：

  • 自由式工作：这些允许您在单个计算机或标签（计算机组，例如“Windows-XP-32”）上构建您的项目。
  • 多配置作业：这些允许您在多台计算机或标签或两者的混合上构建项目，例如 Windows-XP、Windows-Vista、Windows-7 和 RedHat -对于检查兼容性或构建多个平台很有用（qt 程序？）

如果您有一个想要在 Windows 和 Unix 上构建的项目，您有两种选择：

  • 为每个配置创建一个单独的自由样式作业，在这种情况下，您必须单独维护每个配置
  • 您有一个多配置作业，并且您选择 2 个（或更多）标签/计算机/从属设备 - 1 个用于 Windows，1 个用于 Unix。在这种情况下，您只需为构建维护一项工作

您可以将 gcc 版本保留在一个轴上，将软件版本保留在另一个轴上。没有理由你不应该这样做。

您链接的问题有一个公平点，但与您的问题没有直接关系：在他的情况下，他有一个多配置工作A，成功后触发了另一个工作B。现在，在多配置作业中，如果其中一个配置失败，则整个作业都会失败（显然，因为您希望项目在所有配置上成功构建）。

恕我直言，对于在多个平台上构建相同的项目，更好的方法是使用多配置样式的作业。

于 2011-09-22T14:16:19.373 回答
6

另一种选择是使用 python 构建步骤检查当前操作系统，然后调用适当的设置或构建脚本。在 python 脚本中，您可以将更新的环境保存到文件中，然后使用 EnvInject 插件再次注入环境以进行后续构建步骤。根据构建环境的大小，您还可以使用像 SCons 这样的多平台构建工具。

于 2012-09-29T03:38:08.147 回答
4

一个选项是使用用户定义的轴结合从属（windows，linux，...），因此您需要为每个组合添加一个过滤器并使用 Conditional BuildStep Plugin 为每个平台设置特定的构建步骤（Executar shell , Windows 命令, ...)

这个链接有一个教程，但它是葡萄牙语的，但它很容易根据图像来解决...... http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas-configuracoes-matrix-没有詹金斯/

于 2013-06-21T01:55:19.443 回答
4

您可以创建一个脚本（例如build）和一个批处理文件（例如build.bat），它们会与您的源代码一起签入。在 Jenkins 的构建步骤中，您可以调用$WORKSPACE/build - Windows 将执行build.bat而 Linux 将运行build。

于 2012-07-10T15:40:02.970 回答
2

如果您使用 Windows 和其他东西走矩阵路线，您将需要 XShell 插件。您只需创建两个构建脚本，例如用于 cmd 的“build.bat”和用于 bash 的“build”，然后告诉 XShell 运行“build”。在每种情况下都会运行正确的。

于 2012-10-19T03:52:57.880 回答
2

您可以使用 jenkins 在定义配置矩阵轴时创建的变量。例如：您创建一个名为 OSTYPE 的从轴并检查两个从轴（Windows 和 Linux）。然后创建两个单独的构建步骤并检查 OSTYPE 环境变量。

您可以改用改进的脚本语言，例如 python，它是多平台的，并且可以在一个构建步骤中实现独立于从属名称的相同功能。

于 2012-01-26T23:16:07.703 回答
1

在 Windows 上运行批处理文件和在 Unix 上运行 shell 脚本的 hack：

在 Unix 上，使批处理文件以 0 退出状态退出：

ln -s /bin/true /bin/cmd

在 Windows 上，找到一个true.exe，命名它sh.exe并将其放置在 PATH 中的某个位置。

或者，如果您sh.exe在 Windows 上安装了任何软件（来自 Cygwin、Git 或其他来源），请将其添加到 Jenkins 的 shell 脚本顶部：

[ -n "$WINDIR" ] && exit 0

于 2013-09-20T11:05:34.023 回答
1

为什么不总是选择多配置作业类型？

想到了一些原因：

  1. 因为作业应该易于创建和配置。如果很难在您的环境中配置任何作业，那么您可能在 jenkins 作业范围之外做错了什么。如果你很高兴你成功地创建了一个工作并且它最终运行了，并且你不愿意再次完成整个工作，那么这就是你应该尝试改进的地方。
  2. 因为多配置作业更复杂。它们通常要求您同时考虑主要工作和不同的子工作变量，并且它们的复杂性往往会增长到无法管理的水平。因此，在单个工作场景中，您可能会浪费思想不使用这种复杂性，并且在扩展构建变量时，事情可能会朝着错误的方向发展。我建议默认使用简单作业，仅在需要多个配置时才使用多配置作业。
  3. 因为执行多配置作业可能需要比单个作业更多的从属作业槽。总会有一个主作业在一个特殊的、不可见的插槽上执行（这本身没问题）并触发子作业，但是如果这些子作业自己触发了子作业，如果有的话，你可能很容易陷入死锁子作业比插槽多，并且一些子作业再次触发子作业，然后由于没有更多可用插槽而无法执行。这个问题可以通过在从站上使用一些配置设置来规避，但它存在并且可能仅在多个多作业同时运行时才会发生。

所以本质上：多配置作业是一个更复杂的事情，因为除非必要，否则应该避免复杂性，所以常规的自由式作业是更好的默认设置。

于 2014-06-30T12:34:45.673 回答
0

如果要选择在哪个从站上运行作业，则需要使用多配置项目（否则您将无法选择/限制运行它的从站 - 有三种方法可以做到，但是我已经全部尝试过了（Tie 插件仅适用于主作业，高级项目选项中的限制也不是安全触发器，因此您想使用已被证明可以正常工作的从轴。）

于 2015-08-17T13:34:13.837 回答