Build 我们如何使用Jenkins发布涉及多个平台的版本？

我们的构建机器有点混乱

我最终成功地实现了一个矩阵构建，这是一个“首先检查所有内容是否已编译”类型的任务，它只编译当前平台上运行的所有内容。它可以在多个平台上运行（唯一的问题是，它可能会多次编译java代码，但可能会优化一次）

我想为“构建安装程序”建立一个矩阵构建也不会太难

但有两个问题肯定会受到影响

我们重新分发了一个zip文件，理想情况下，它将在一个zip文件中包含所有依赖于平台的二进制文件，以减少重复（本质上，它是一个我们分发给其他人的库）

我们将实际版本复制到服务器的过程依赖于在构建开始之前为相同产品的相同版本号生成的每个文件。没有任何一个操作系统构建能够完整地查看生成的文件，从而能够发布该版本，而且似乎不可能添加在父作业中运行的构建步骤

我们正在使用Archive for Clone Workspace SCM作为此初始矩阵构建的后期构建步骤，但它似乎在每个操作系统上独立运行，并且没有尝试将结果合并在一起

其他人如何回避这些问题

我知道我可以完全抛弃矩阵构建，通过配置每个作业的多个来完成所有工作，但我们现在有三个平台，作业数量将猛增

---

包括詹金斯替代品的选择也将被认真考虑，就像最近。。。我们在这方面遇到的问题非常多。

以下是我们最终建立的有效机制：

• “平台发布”项目仍然是一个“矩阵构建”
• 每个从机都使用其相关平台进行标记，我们使用从机标签作为矩阵的参数
• “归档工件”用于归档有用的文件。（“使用矩阵构建时，克隆工作区SCM”似乎是一条死胡同。）
• 项目“统一版本”是一个普通的构建，它从平台版本复制工件。由于我们复制工件而不指定特定的平台，因此我们获得所有平台的工件，这些工件出现在名为

  /os/windows

  、

  /os/macosx

  等目录中
• Ant构建知道工件的位置（它们在工作副本之外），并在上传之前将所有文件拉入单个目录结构
• “参数化触发器”插件是为平台版本设置的，用于触发统一版本，以便它使用的svn版本与实际生成的文件匹配。不幸的是，尽管只使用了存储库的一小部分，但我们必须签出整个存储库，因为存在一个bug（怀疑在subversion插件中），它阻止使用正确的版本签出子目录