如何在 Hudson 中指定必备作业
我有一份 Hudson 工作，只对第三方库进行签出/更新。将此作业称为作业 A。
其他几个作业依赖于该库。称他们为作业 B 和 C。他们使用作业 A 签出的内容，并且需要它是最新的。
我的问题是，如何要求作业 B 和 C 在运行构建例程之前始终运行作业 A（以更新库）？
如果这是不可能的，有人可以推荐另一种方法来达到相同的效果吗？
I have a Hudson job that just does a check-out/update to a third-party library. Call this Job A.
Several other jobs depend on this library. Call them Jobs B and C. They use the stuff checked out by Job A, and need it to be up-to-date.
My question is, how can I require Jobs B and C to always run Job A (to update the library) before they run through their build routine?
If this is not possible, can someone recommend another way to achieve the same effect?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以通过“子”作业以另一种方式完成此操作。例如，您可以配置A成功后触发B和C。 （您可以在作业 A 配置页面上找到该选项）。
如果您需要更高级的条件来触发子作业，您可以查看 参数化触发器插件。
You can do it the other way with "child" jobs. For example, you can configure A to trigger B and C after it has succeeded. (You will find the option on job A configuration page).
If you need more advanced conditions for triggering the child jobs, you can take a look at the Parametrized Trigger plugin.
经过进一步思考这个问题，我想我可能把事情过于复杂化了。
由于作业 A 中的库很少更新，因此我们认为仅定期扫描 SVN 并在发生更改时进行更新可能是可以接受的。如果 B 和 C 的构建在签入 A 的更改后立即开始，则 B 和 C 的构建有可能会错过库更改，但这很少会成为问题。
After thinking about the problem some more, I think I may have been over-complicating things.
Since the library in Job A is rarely updated, we decided it's probably acceptable to just scan SVN on an interval and update when there are changes. There's a small possibility that builds of B and C will miss library changes if they start right after the changes to A were checked in, but that should rarely be an issue.
如果我关注您，听起来您可能需要加入插件 ：
此插件允许在所有直接下游作业完成后运行作业。这样，执行可以分支并并行执行许多步骤，然后在所有并行工作完成后仅运行一次最终聚合步骤。该插件对于创建“钻石”形状项目依赖项非常有用。这意味着有一个单父作业启动多个下游作业。这些作业完成后，将运行一个聚合作业
If I follow you, it sounds like you might need the Join plugin:
This plugin allows a job to be run after all the immediate downstream jobs have completed. In this way, the execution can branch out and perform many steps in parallel, and then run a final aggregation step just once after all the parallel work is finished. The plugin is useful for creating a 'diamond' shape project dependency. This means there is a single parent job that starts several downstream jobs. Once those jobs are finished, a single aggregation job runs