是否可以在 Hudson/Jenkins 中交错构建？
我设置了 Jenkins 来为不同平台构建 XBMC 映像。我的系统大约需要 6 小时来构建每个映像，因此我更喜欢并行运行它们，通常一次 2 或 3 个。这样做的问题是，如果他们必须下载模块的更新（如 linux 内核或某些），则并行的 2 或 3 个构建将同时下载，从而损坏下载（它们指向同一个文件夹）
是吗？可以在 jenkins/hudson 中指定偏移量吗？ （我知道您可以安排构建，以及使用在一个项目完成后构建的触发器），例如：
构建 1：立即
构建 2：构建 1 后 20 分钟开始
构建 3：构建 2 后 20 分钟开始
我尝试查看对于插件以及谷歌，但没有运气。我还知道我可以通过 jenkins 中类似 cron 的调度功能进行调度，但我设置了构建触发器来轮询 GIT 存储库以查找构建的更改，我不仅仅是盲目调度。
I have Jenkins set up to build XBMC images for different platforms. My system takes around 6 hours to build each image, so I prefer to run them in parallel, usually 2 or 3 at a time. The problem with this is, that if they have to download updates to modules (like linux kernel or sometihng), the 2 or 3 building in parallel will download at the same time, corrupting the download (they point to the same folder)
Is it possible in jenkins/hudson to specify an offset? (I know you can schedule builds, as well as use a trigger that builds after completion of one project) something like:
Build 1: immediately
Build 2: start 20 minutes after build 1
Build 3: start 20 minutes after build 2
I tried looking for a plugin as well as google but no luck. I also know that I could schedule via the cron-like schedule capabilities in jenkins, but I have my build trigger set up to poll the GIT repo to look for changes for a build, I'm not just blind scheduling.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一种方法是选择“高级”下的“安静期”选项。
将作业 2 设置为 1200 秒，将作业 3 设置为 2400 秒。
这意味着当 git 中发现更改时，作业 1 将立即排队，作业 2 将延迟 20 分钟进入队列，作业 3 将延迟 20 分钟进入队列。延误了40分钟。
One way to do it is to choose the "Quiet Period" option under "Advanced".
Set it to 1200 seconds for Job 2, and 2400 seconds for Job 3.
That means Job 1 will be queued immediately when a change is noticed in git, Job 2 will go into the queue with a 20 minute delay, and Job 3 with a 40 minute delay.
另一种方法是使作业成为某种构建流程（无论是使用构建流程插件还是通过说作业 A 的最后一个任务是运行作业 B）。如果您可以将下载变成它自己的作业，那么您可以将“下载”作业定义为单线程，而将其余作业定义为多线程。
执行此操作仅序列化需要序列化的内容。当下载需要十五分钟时，“每二十分钟”执行一次操作会浪费时间，并且当速度减慢且下载需要二十五分钟时，将会失败（可能以难以调试的方式）。
Another way to do this would be to make the job some sort of a build flow (whether with the build flow plugin or by saying that the last task of job A is to run job B). If you can turn the download into its own job, then you can define the "download" job as single-threaded, and the rest as multithreaded.
Doing this serializes only what needs to be serialized. Doing an "every twenty minutes" thing will waste time when it takes fifteen minutes to download, and will fail (possibly in a hard-to-debug way) when there's a slowdown and it takes twenty-five minutes to download.