Hudson 的替代构建管理器
我在一家软件公司工作，我们的主要开发语言是 Java。当然，我们使用 Hudson 进行持续构建，它的表现非常出色。然而，Hudson 并不擅长我们要求它做的其他一些事情。我们还使用 Hudson 作业来部署二进制文件、刷新数据库、运行负载测试、运行回归等。当存在构建依赖项时（即负载测试需要数据库刷新），我们确实会遇到麻烦。
这是 Hudson 没有做但我们真正需要的一件事：
构建依赖关系：它支持 Ant 构建的构建依赖关系，但不支持 Hudson 作业。我们使用 URL 调用功能来使 Hudson 作业调用另一个 Hudson 作业。问题是 Hudson 总是返回 200 并且在工作完成之前不会阻塞。这意味着调用作业不知道 a) 构建是否失败，以及 b) 如果没有失败，则需要多长时间。
如果不必使用 shell 脚本来指定构建的行为，那就太好了，但这并不是完全必要的。
任何方向都会很好。也许我们没有以正确的方式使用 Hudson（即所有构建都应该是 Ant 构建吗？）或者我们可能需要另一个产品来进行一键部署、负载测试、迁移、数据库刷新等。
编辑：
，我们的构建中有一些参数，根据参数的不同，这些参数可能会导致不同的依赖关系。即，有时我们希望通过数据库刷新进行负载测试，有时不需要数据库刷新。不幸的是，为每个参数组合创建一个 Hudson 作业（如 Join 插件所需）是行不通的，因为有时不同的组合可能会导致数十个作业。
I work at a software company where our primary development language is Java. Naturally, we use Hudson for continuous builds, which it works brilliantly for. However, Hudson is not so good at some of the other things we ask it to do. We also use Hudson jobs to deploy binaries, refresh databases, run load testing, run regressions, etc. We really run into trouble when there are build dependencies (i.e. load testings requires DB refresh).
Here's the one thing that Hudson doesn't do that we really need:
Build dependency: It supports build dependencies for Ant builds, but not for Hudson jobs. We're using the URL invocation feature to cause a Hudson job to invoke another Hudson job. The problem is that Hudson always returns a 200 and does not block until the job is done. This means that the calling job doesn't know a) if the build failed and b) if it didn't fail, how long it took.
It would be nice to not have to use shell scripting to specify the behavior of a build, but that's not totally necessary.
Any direction would be nice. Perhaps we're not using Hudson the right way (i.e. should all builds be Ant builds?) or perhaps we need another product for our one-click deployment, load testing, migration, DB refresh, etc.
Edit:
To clarify, we have parameters in our builds that can cause different dependencies depending on the parameters. I.e. sometimes we want load testing with a DB refresh, sometimes without a DB refresh. Unfortunately, creating a Hudson job for each combination of parameters (as the Join plugin requires) won't work because sometimes the different combinations could lead to dozens of jobs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为我不理解您的“构建依赖项”要求。任何 Hudson 作业都可以配置为触发另一个（下游）作业，或由另一个（上游）作业触发。
Downstream-Ext 插件 和 加入插件 允许更复杂的构建依赖项定义。
I don't think I understand your "build dependency" requirements. Any Hudson job can be configured to trigger another (downstream) job, or be triggered by another (upstream) job.
The Downstream-Ext plugin and Join plugin allow for more complex definition of build dependencies.
Hudson 有一个 CLI，它允许您向 Hudson 实例发出命令。使用“帮助”来获取准确的详细信息。我相信有一个可以让您调用构建并等待其完成。
http://wiki.hudson-ci.org/display/HUDSON/Hudson+CLI
There is a CLI for Hudson which allows you to issue commands to a Hudson instance. Use "help" to get precise details. I believe there is one which allows you to invoke a build and await its finish.
http://wiki.hudson-ci.org/display/HUDSON/Hudson+CLI
您是否需要一份额外的工作来满足您的“依赖”？
对我来说，您的依赖项听起来像是一个额外的构建步骤。刷新数据库的脚本可以存储在您的 scm 中，每个需要此步骤的构建都会检查它。如果您的参数“数据库刷新”为 true，则可以调用该脚本。这可以通过多个模块来完成。优点是什么？您的脚本逻辑位于您的 scm 中（拥有更改历史记录总是好的）。您仍然可以为所有测试作业更新一次脚本（因为大家都签出了相同的脚本）。此外，您不需要查看多个脚本来确定测试是否成功运行。特别是如果您的一项作业属于多个执行线的一部分，则很难找出哪个作业触发了哪个运行。另一个优点是 Hudson 上的工作较少，因此更容易维护。
Do you need an extra job for your 'dependencies'?
Your dependencies sound for me like an extra build step. The script that refreshes the DB can be stored in your scm and every build that needs this step will check it out. You can invoke that script if your parameter "db refresh" is true. This can be done with more than just one of your modules. What is the advantage? Your script logic is in your scm (It's always good to have a history of the changes). You still have the ability to update the script once for all your test jobs (since hey all check out the same script). In addition you don't need to look at several scripts to find out whether your test ran successful or not. Especially if you have one job that is part of several execution lines, it becomes difficult to find out what job triggered which run. Another advantage is that you have less jobs on your Hudson and therefore it is easier to maintain.
我认为您正在寻找的是 http://wiki.jenkins-ci .org/display/JENKINS/Parameterized+Trigger+Plugin 该插件可让您根据先前作业的状态执行其他作业。您甚至可以从下游项目调用 shell 脚本来确定任何其他条件。进而可以调用 API 来获取更多信息。
例如，我们有一个构建后步骤来通知我们，这会回调 JSON API 以在我们的 IRC 频道中构建一个不错的主题，其中显示“所有构建正常”或“X,Y 失败”等。
I think what you are looking for is http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin This plugin lets you execute other jobs based on the status of previous jobs. You can even call a shell script from the downstream project to determine any additional conditions. which can in turn call the API for more info.
For example we have a post-build step to notify us, this calls back the JSON API to build a nice topic in our IRC channel that says "All builds ok" or "X,Y failed" , etc.