|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
You can use the stage step to limit concurrency. Compared to the checkbox in job config that we are accustomed to from freestyle projects, this is more flexible, since you can conditionally allow parallelism, or serialize only certain stages, etc. It also offers better auditability: a build is “started” as soon as it enters the queue, and you can see in the build record when it started, how long it waited to enter the stage, and when it actually started doing work. If multiple builds are waiting, the earlier ones will get canceled (NOT_BUILT), so you can track this too—for a freestyle project the queue coalescing leaves no trace.
On the other hand, for simple use cases such auditability is overkill and the verbosity of having so many build records is just an annoyance, hence this RFE.
There is some technical subtlety around queue item coalescing. Normally any two items from the same job are coalesced. But if there is a QueueAction in play then this behavior can be conditionally suppressed. By far the most common case is build parameters: two queue items of a parameterized job are coalesced only if all the parameters match. This behavior could be simulated fairly easily in a Workflow script as well: just define the stage name according to the parameter values (which also makes it clear how you could fine-tune the behavior if needed). On the other hand, if you are using one of the rare plugins that defines a QueueAction—such as the Git plugin, which allows a build to be triggered with a specific commit ID rather than generically against the configured branch—then this special behavior could not automatically be simulated from your flow script, since it might not have access to the relevant information, or the decision to coalesce or not might involve complex calculations (as with the Jenkins Enterprise validated merge plugin, whose QueueAction checks for an ancestry relation between two Git commits).