jenkins和多configuration（matrix）工作
为什么jenkins有两种工作，多configuration项目和自由式项目项目？ 我读过某处，一旦你select其中一个，你就不能转换到另一个（很容易）。 为什么我不能总是select多configuration项目，以保证未来的变化安全？
我想为Windows和Unix（以及其他平台）上的项目构build一个构build版本。 我发现了这个问题 ），它提出了同样的问题，但我没有真正得到答案。 为什么我需要三个matrix项目（而不是三个自由式项目），每个平台一个？ 为什么我不能把它们全部放在一个matrix中，在一个轴上使用平台AND（例如）gcc版本，而在另一个轴上使用（我的）软件版本？
我也读过这篇博客文章 ，但是在同一台机器上构build了所有的东西，只有不同的Python版本。
简而言之，大多数人如何configuration针对多个不同平台的多configuration项目？
这两类工作有不同的function：
- 自由风格的作业：这些作业可以让你在一台计算机或者标签（一组计算机，例如“Windows-XP-32”）上构build项目。
- 多configuration作业：这些作业允许您在多台计算机或标签上或两者的组合（例如Windows-XP，Windows-Vista，Windows-7和RedHat）上构build项目，这对于检查兼容性或为多平台构build（qt程序？）
如果你有一个你想在Windows和Unix上构build的项目，你有两个select：
- 为每个configuration创build一个单独的自由式作业，在这种情况下，您必须单独维护每个configuration
- 您有一个多configuration作业，并且您select2个（或更多）标签/计算机/从属 – Windows 1和Unix 1。 在这种情况下，你只需要维护一个工作的构build
你可以保留你的gcc版本在一个轴上，软件版本在另一个轴上。 没有理由你不应该能够。
你连接的问题有一个公平的点，但是直接与你的问题没有关系：在他的情况下，他有一个多configuration的工作A ，成功地引发了另一个工作B。 现在，在多configuration作业中，如果其中一个configuration失败，则整个作业将失败（显然，因为您希望项目在所有configuration上成功构build）。
恕我直言，为了在多个平台上构build相同的项目，最好的方法是使用多configuration风格的作业。
另一个select是使用python构build步骤来检查当前的操作系统，然后调用适当的设置或构build脚本。 在python脚本中，可以将更新后的环境保存到一个文件中，并使用EnvInject插件为后续构build步骤再次注入环境。 根据您的构build环境的大小，您也可以使用像SCons这样的多平台构build工具。
你可以创build一个脚本（比如build ）和一个batch file（比如build.bat ），它们会被源代码检入。 在Jenkins的构build步骤中，您可以调用$ WORKSPACE / build – Windows将执行build.bat，而Linux将运行构build 。
一个选项是使用用户定义轴与奴隶（Windows，Linux，…），所以你需要为每个组合添加一个filter，并使用条件BuildStep插件设置特定的每个Plataform的构build步骤（Executarshell，Windows命令，…）
这个链接有一个教程，但它是在葡萄牙语，但它很容易工作，基于图像… http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas-configuracoes-matrix-无jenkins/
您可以使用jenkins在定义configurationmatrix轴时创build的variables。 例如：创build名称为OSTYPE的从轴，并检查两个从轴（Windows和Linux）。 然后创build两个单独的构build步骤，并检查OSTYPE环境variables。
您可以使用改进的脚本语言，如python，它是多平台的，可以独立于从站的名称并在一个构build步骤中实现相同的function。
如果你使用Windows和其他的东西，你会需要XShell插件。 您只需创build两个构build脚本，如cmd的“build.bat”和bash的“build”，然后告诉XShell运行“构build”。 正确的一个将在每种情况下运行。
在Windows上运行batch file并在Unix上运行shell脚本：
在Unix上，使batch file以0退出状态退出：
ln -s /bin/true /bin/cmd
在Windows上，find一个true.exe ，将其命名为sh.exe ，并将其放在PATH的某处。
或者，如果您在Windows上安装了任何sh.exe （来自Cygwin，Git或其他源），请将其添加到Jenkins中的shell脚本的顶部：
[ -n "$WINDIR" ] && exit 0
为什么不总是select多configuration作业types？
有些原因让人想起来：
- 因为作业应该很容易创build和configuration。 如果在您的环境中很难configuration任何工作，那么您可能在jenkins工作范围之外做了一些错误的工作。 如果你很高兴能够创造出这样一份工作，并且最终能够继续下去，而你又不愿意再做这个工作，那么你应该尝试改进。
- 因为多configuration作业更复杂。 他们通常会要求你考虑主要工作和不同的子工作variables，而且他们往往会变得越来越难以pipe理。 所以在一个单一的工作场景中，你可能会浪费掉不考虑复杂性的想法，而当扩展构buildvariables时，事情可能会朝着错误的方向发展。 我build议使用简单的作业默认，多configuration作业只有当需要多个configuration。
- 因为执行多个configuration作业可能需要比单个作业更多的作业位置。 总是有一个主要的工作是在一个特殊的，不可见的插槽上执行的（这本身没有问题）并触发子作业，但是如果这些子作业本身触发子作业，那么如果存在更多的子作业比插槽，一些子作业再次触发子作业，然后不能执行，因为没有更多的空位。 通过在从服务器上使用一些configuration设置，可能会绕过这个问题，但是它是存在的，并且只有在多个多任务同时运行时才会出现。
所以本质上说：多configuration工作是一个更复杂的事情，因为复杂性应该避免，除非必要，常规自由式工作是一个更好的默认。
如果要select运行哪个从属作业，则需要使用多configuration项目（否则，您将无法select/限制运行它的从属设备 – 有三种方法可以完成此任务，但是，已经全部试过了（Tie插件只能用于主作业，高级项目选项中的Restrict并不是摇滚安全的触发器，所以你想使用被certificate今天正常工作的从轴。
