logo标签列表

Jenkins和多配置（矩阵）作业

jenkinscontinuous-integrationmulti-configuration
39
为什么Jenkins有两种工作类型，即多配置项目和自由样式项目？我在某个地方读到过，一旦选择了其中一种，就不能轻松地转换到另一种。为什么我不总是选择多配置项目以便于未来的更改？
我想为一个项目设置构建，该项目在Windows和Unix（以及其他平台）上都可以构建。我发现这个问题，它问的是同样的事情，但我真的不明白答案。为什么我需要三个矩阵项目（而不是三个自由样式项目），每个平台一个？为什么我不能将它们全部放在一个矩阵中，其中包括平台和（例如）gcc版本在一个轴上，以及我的软件版本在另一个轴上？
我还阅读了这篇博客文章，但那是在同一台机器上构建所有内容，只是使用不同的Python版本。
简而言之：大多数人如何配置针对许多不同平台的多配置项目？
为什么我不应该总是选择多配置项目以便将来更改时更安全呢？我认为这部分没有回答 - 与自由样式项目相比，选择它是否存在任何问题？ - Matt R
9个回答
43

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

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

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

  • 为每个配置创建一个独立的自由式工作，这样您需要单独维护每个工作任务
  • 您可以选择一个多配置工作，并选择两个（或更多）标签/计算机/从属机 - 一个用于Windows，一个用于Unix。在这种情况下，您只需维护一个构建作业

您可以将您的gcc版本放在一个轴上，将软件版本放在另一个轴上。没有理由不能这样做。

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

我的看法是，对于在多个平台上构建同一项目，更好的方法是使用多配置风格的工作任务。

4
很好的回答！不过我有一个问题：我该如何让Jenkins只在Windows构建服务器上运行Windows批处理文件，而只在Linux构建服务器上运行shell脚本？在我的当前配置（多项目）下，似乎它也在Windows上尝试启动shell脚本。 - joscarsson
1
这是唯一的问题 - 我曾经在考虑是否应该输入它，因为它似乎会让很多人感到沮丧 :)如果您可以创建一个等效的shell脚本并安装了bash或cygwin，则可以使用该脚本。如果没有，您的唯一选择就是创建单独的作业。批处理文件中是否有特殊内容无法转换为shell脚本？ - Sagar
我明白了。我采取了简单的方法，将构建分成不同的自由风格项目。我读到有些人正在使用跨平台构建脚本，如Ant。 - joscarsson
1
我的问题是我在Visual Studio和Windows中使用devenv.com，在Unix上使用automake，而且我找不到一个简单的方法来使相同的脚本在这两个平台上运行。 - joscarsson
没问题！是的，我们的解决方案是使用ant，但我不知道你如何在devenv中实现。祝你好运！ - Sagar
1
XShell插件提供了另一种选择，可以定义一个在Windows或类Unix变体（如Linux、FreeBSD、OpenBSD、MacOS）上运行的单个命令。但是，XShell插件的实际限制意味着它通常只能启动您选择的脚本（例如build.bat或构建shell脚本）。 - Mark Waite
6

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

基于Python的构建工具具有在多个平台上更容易部署的优势。我们使用“doit”，为了确保文件操作在任何地方都能正常工作，我们使用优秀的“py”模块（from py.path import local）。 - Jan Vlcinsky
4
您可以创建一个脚本（例如build）和一个批处理文件（例如build.bat），并将其与您的源代码一起检入。在Jenkins中，在构建步骤中，您可以调用$WORKSPACE/build - Windows将执行build.bat，而Linux将运行build。
4
我应该将该构建步骤设置为“执行 Windows 批处理命令”还是“执行 shell”？ - joscarsson
4
2
如果您选择在Windows和其他平台上使用矩阵路线，您将需要使用XShell插件。您只需创建两个构建脚本，例如"build.bat"用于cmd和"build"用于bash，并告诉XShell运行"build"。每种情况下都会运行正确的脚本。
2
你可以使用Jenkins创建的变量来定义配置矩阵轴。例如，你可以创建一个名为OSTYPE的从节点轴并选择两个从节点（Windows和Linux）。然后，你可以创建两个单独的构建步骤，并检查OSTYPE环境变量。
你也可以使用一种更先进的脚本语言，比如Python，它是跨平台的，可以在一个构建步骤中独立于从节点名称实现相同的功能。
那其实是一个相当不错的想法！没有想到可以这样使用环境变量，我总是得出需要一个脚本在两个平台上运行的结论。谢谢你的提示！ - joscarsson
...或者不是吗？ :) 我刚刚测试了一下。我仍然需要指定构建步骤为“执行Windows批处理命令”或“执行shell”，如果同时在两个平台上指定，构建将在两个平台上都失败。 - joscarsson
1
@joscarsson 你尝试过使用“条件构建步骤插件”吗？这样你就可以根据操作系统类型运行一个步骤。我没有尝试过，如果这对你有用，请回复我！ - jan
1

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

有一些原因可以想到：

  • 因为工作应该易于创建和配置。如果在您的环境中很难配置任何作业，则可能是超出了Jenkins作业范围的问题。如果您很高兴已经成功创建了一个作业并最终运行，而且不愿意再做这项工作，那么您应该尝试改进。
  • 因为多配置作业更加复杂。它们通常要求您考虑主要作业和不同的子作业变量，并且它们往往会增长到无法管理的复杂程度。因此，在单个作业场景中，您可能会浪费思考如何不使用该复杂性，当扩展构建变量时，事情可能会朝着错误的方向发展。我建议默认使用简单作业，只有在需要多个配置的情况下才使用多配置作业。
  • 因为执行多配置作业可能需要更多的作业插槽。始终会有一个主作业在特殊的不可见插槽上执行（本身没有问题）并触发子作业，但如果这些子作业自己触发子作业，如果子作业数量超过插槽数量，您可能很容易陷入死锁状态，并且一些子作业再次触发子作业，然后不能执行，因为没有更多的空闲插槽。这个问题可以通过在从机器上使用一些配置设置来解决，但它确实存在，并且只有在同时运行多个多作业时才可能发生。
    • 因此，多配置作业是一种更复杂的东西，由于应尽量避免复杂性，因此常规自由风格作业是更好的默认选择。
    1

    一个在Windows上运行批处理文件和在Unix上运行shell脚本的技巧：

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

    ln -s /bin/true /bin/cmd

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

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

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

    0

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

    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接