Warnings plugin causing concurrent builds to finish slower?

[mandeepr]

It seems that the Warnings plugin is making my concurrent builds to
finish one after the other, as opposed to the shortest time possible.
I read that this was a problem with concurrent builds for the Instant
Messaging plugin:

"the plugin will serialize all builds for a job which is configured
with the Execute concurrent builds option. Means: build n can never
finish before build n+1. If needed build n+1 will wait until n
finishes even if n+1 would have finished long before n. This is
required, because the plugin needs to compute the exact build result
(e.g. for FIXED, STILL FAILING, STILL UNSTABLE)"

Does anyone know if this is the same issue with the Warnings plugin?

Thanks,
Mandeep

[Ullrich Hafner]

Yes that is the same (or at least similar), I'm using the following
synchronization:

BuildStepMonitor.STEP
This BuildStep is only executed after the same step in the previous
build is completed. For build steps that use a weaker assumption and
only rely on the output from the same build step of the early builds,
this improves the concurrency.

That means, the warnings computation n+1 needs to wait for warnings
computation n. Otherwise it would not be possible to compute the number
of new warnings.

Ulli

[Mandeep Rai]

Thanks for the prompt reply!

[Nord, James]

Would it be at all possible to implement an option to bypass this?

For a lot of builds the "new" issues is meaningless as there is no linear relationship (an older build could be based on newer software - esp in the case of building multiple branches - or code review builds!)


**************************************************************************************
This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postm...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary.

NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00
**************************************************************************************

[Ulli Hafner]

Yes that would be possible and shouldn't be complicated. Can you please
create an issue in our issue tracker?

Thanks, Ulli

[Nord, James]

>> BuildStepMonitor.STEP
>> This BuildStep is only executed after the same step in the
>> previous build is completed. For build steps that use a weaker
>> assumption and only rely on the output from the same build step of
>> the early builds, this improves the concurrency.
>>
>> That means, the warnings computation n+1 needs to wait for warnings
>> computation n. Otherwise it would not be possible to compute the
>> number of new warnings.
> Would it be at all possible to implement an option to bypass this?
>
> For a lot of builds the "new" issues is meaningless as there is no
> linear relationship (an older build could be based on newer software -
> esp in the case of building multiple branches - or code review
> builds!)
>
>

| Yes that would be possible and shouldn't be complicated. Can you please create an issue in our issue tracker?

Done https://issues.jenkins-ci.org/browse/JENKINS-11761