Status: Reopened (View Workflow)
Claim plugin 2.2
When executing builds in parallel*, some post-build actions force the builds to end in the same order they were started. Even if build #2 is ready, it has to wait until build #1 is done. Claim plugin is one such plugin that serializes build order.
Would it be possible to fix the plugin such that it would not block later builds from finishing even if earlier build was still ongoing?
*) option "Execute concurrent builds if necessary" in project configuration
"Executor #4 for master : executing project-x #2 : waiting for Check point hudson.plugins.claim.ClaimPublisher on project-x #1" Id=96 Group=main WAITING on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d at java.lang.Object.wait(Native Method) - waiting on hudson.model.Run$RunExecution$CheckpointSet@3fd2670d at java.lang.Object.wait(Object.java:485) at hudson.model.Run$RunExecution$CheckpointSet.waitForCheckPoint(Run.java:1453) at hudson.model.Run.waitForCheckpoint(Run.java:1411) at hudson.model.CheckPoint.block(CheckPoint.java:144) at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:25) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:802) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:774) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:724) at hudson.model.Run.execute(Run.java:1617) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237)
- is related to
JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
- relates to
JENKINS-43658 Concurrent builds are serialized when publishing
This issue can't be fixed without removing the sticky functionality
Christian: Would it be possible to make this conditional on sticky being enabled?
I think it is possible, although as I see it the sticky functionality is very central and something that most(if not all) users would like.
A user already has the option to not use that claim plugin at all if it wants true concurrents builds.
Surely this is resolvable in the code. If build succeeds we don't care about preceeding Claims. If build fails we register a listener on previous build and update the claim as appropriate. This would be rather more delicate code but entirely doable.
If the behaviour won't be changed, I think the inline configuration help for "Allow broken build claiming" should warn the user that concurrent builds will be affected.
I'm not using Claim plugin at present, but I think
JENKINS-27206 (Pipeline support) touched on this part of the code. From the look of it, sticky claims might unstick when concurrent builds are running.
Probably because of: "Claims may be made sticky to follow the user claiming the failure until the build is successful again."
If build N fails and is claimed sticky, result of build N+1 needs to be known to determine whether the claim extends to N+2; so the latter cannot finish before the former.