Details
-
Bug
-
Status: Reopened (View Workflow)
-
Major
-
Resolution: Unresolved
-
Jenkins 1.509.3
Claim plugin 2.2
Description
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)
Attachments
Issue Links
- is related to
-
-
- Resolved
-
- relates to
-
-
- Closed
-
Activity
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.
Sean Flanigan
added a comment - 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.
Sean Flanigan
added a comment - 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. Sean Flanigan
added a comment - 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.
Sean Flanigan
added a comment - 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.