Jenkins构建队列限制 [英] Jenkins Build Queue Limit

问题描述

我注意到，詹金斯（Jenkins）似乎有一个构建队列限制。当我触发很多构建时，似乎最多只能在构建队列中放置一个构建。有没有办法消除此限制，以便在构建队列中可以有一个以上的构建？

解决方案

这是预期的行为：

• 通常，您的工作将取决于某些输入（来自SCM或某些上游工作）


• 如果您的从属容量太低而无法赶上每个构建，那么通常您只想测试/构建/ ...仅是最新的项目。
li>

这是默认行为。否则，存在构建队列无限期增长的风险。

最重要的是，Jenkins不会跟踪正常构建请求的属性-所有这些看起来是一样的，Jenkins不能（例如）分离在不同触发时间存在的不同SCM状态。

然而，这正是为您提供解决方法：参数化您的工作，然后使用例如在其他项目上触发参数化的构建后生成操作来触发这些操作。然后Jenkins将每个构建请求单独排队-在您的工作中，您可以使用该参数找出必须完成的工作。

I think ，詹金斯甚至不会压榨具有相同参数值的排队参数化构建，因此即使某些始终具有相同值的虚拟参数也应该这样做（但最好先对此进行测试）。 / p>

I've noticed that there seems to be a build queue limit of one in Jenkins. When I trigger a lot of builds it seems to only place a max of one build in the build queue. Is there a way to remove this limit so there can be more then one build in the build queue?

解决方案

This is intended behaviour:

• Normally, your jobs will depend on some input (from SCM, or from some upstream jobs)
• If your slave capacity is too low to catch up with each and every build, then you'd normally want to test/build/... only the very latest "item".

This is the default behaviour. Without that, there'd be a risk that the build queue grows indefinitely.

On top of that, Jenkins does not track the properties of normal build requests -- they all look the same, and Jenkins can not (for example) separate different SCM states that existed at different triggering times.

This is however exactly the point that gives you a workaround: parameterize your jobs, and then use for example the Trigger parameterized build on other projects post-build action to trigger those. Then Jenkins will queue each build request individually -- and inside your job, you can use the parameter to find out what exactly has to be done.

I think that Jenkins will not even squash queued parameterized builds that have identical parameter values, so even some dummy parameter that has the same value all the time should do (but better test this first).

这篇关于Jenkins构建队列限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！