Hudson 经验 - 构建矩阵项目
有人尝试过该功能并有一些反馈吗？ 或者有人知道一些有用的样本可供查找吗？
Did anyone try that feature and has some feedback? Or Does anyone know some useful samples to look up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
几个月前我尝试过这个功能，但我不再使用它（只是因为我不需要它，而不是因为它不是一个好功能）。
基本上，您定义 n 个轴，每个轴都是一个具有多个值的属性。
让我们举个例子：您定义了 Axis“JDK”，可能的值为“1.4”、“1.5”、“1.6”，并定义了另一个属性“database”，其中可能的值为“oracle”、“mysql”。
因此，Hudson 将启动您的构建 6 次：
然后，一旦一切完成，您将能够看到每次迭代的结果。
当您需要在多个环境中测试应用程序时（在我的示例中，使用不同版本的 JDK 或数据库），此功能可能非常有用。
请注意，除了 JDK 轴之外，您必须自己管理 Hudson 作为条目给出的属性。 在我的示例中，应用程序必须考虑“数据库”属性本身。 最后，如果您的项目是 Maven 的，一个好主意是使用此属性在 Maven2 配置中启用特定配置文件（请参阅 此处 了解更多详细信息）。
我希望我的解释足够清楚:)
I have tried this feature some months ago, but I don't use it anymore (just because I don't need it, not because it is not a good feature).
Basically, you define n Axis, each axis is a property with several values.
Let's go with an example: you define the Axis "JDK", with possible value "1.4", "1.5", "1.6", and you define another property "database", where possible values are "oracle", "mysql".
Thus, Hudson will launch your build 6 times:
Then, once everything is finished, you will be able to see the results for each iteration.
This feature may be really usefull when you need to test your application in several environments (in my example, with different versions of JDK or database).
Note that except for the JDK axis, you have to manage by yourself the property given as entry by Hudson. In my example, the application must take into account the "database" property itself. Eventually, a good idea is to use this property to enable a particular profile in the Maven2 configuration, if you project is mavenized (see here for more details about that).
I hope my explanations are clear enough :)
Matrix 构建有许多问题：
这是一种耻辱，因为这个概念非常好，而且在发挥作用的地方非常方便。
编辑
我们通常的解决方法是将参数化构建设置为同时运行——这会带来自己的问题，但可以让我们避免许多具有相同代码和不同常量的作业。
Matrix builds have a number of issues:
Which is a shame, because the concept is very good and very handy where it works.
Edit
Our usual way around this is to have parameterized builds set up to run concurrently - which comes with its own problems, but saves us having many jobs with the same code and different constants.