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)
      

          [JENKINS-19820] Claim plugin serializes concurrent builds

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          This issue can't be fixed without removing the sticky functionality

          Christian Bremer added a comment - This issue can't be fixed without removing the sticky functionality

          Daniel Beck added a comment -

          Christian: Would it be possible to make this conditional on sticky being enabled?

          Daniel Beck added a comment - 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.

          Christian Bremer added a comment - 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.

          Marc Carter added a comment -

          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.

          Marc Carter added a comment - 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.

            Unassigned Unassigned
            salsa Sami Salonen
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: