Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59282

Concurrent build support

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: deploy-plugin
    • Labels:
      None
    • Environment:
      Jenkins Version 2.193, deploying to Tomcat 9, using Job DSL
    • Similar Issues:

      Description

      When I configure my build to do concurrent builds they perform right up to the end successfully, but then the later started one waits for the first started job to finish.
      When the first one is finished deploying, the second job continues. It would be great, if there wasn't such a blocker of the concurrent build feature as we have many deployments to do and some more build processor slots available. Help greatly appreciated.

      See also https://issues.jenkins-ci.org/browse/JENKINS-41771

        Attachments

          Activity

          Hide
          jansohn Robin Jansohn added a comment -

          I'm not sure I can follow. You want to deploy the same web application (just different builds) concurrently on one Tomcat? Is that even possible? What about race conditions (build #1 being deployed after build #2)?

          Show
          jansohn Robin Jansohn added a comment - I'm not sure I can follow. You want to deploy the same web application (just different builds) concurrently on one Tomcat? Is that even possible? What about race conditions (build #1 being deployed after build #2)?
          Hide
          anh1979 Anne Hartmann added a comment -

          @Robin Jansohn: Our build process generates a .war file of a certain code-base and changes the application.properties and the name and other configuration values according to a number of params we pass to that job. So the result are multiple applications of the same 'program', and they do not overwrite themselves. This works fine. We use the deploy plugin to put the war over to tomcat manager to install it... I supposed that the call to tomcat manager could be done parallel, because it is a web request, too. But it turns out, when we run concurrent builds, the plugin holds the later job until the first job is finished deploying. Hope I explained to better now.

          Show
          anh1979 Anne Hartmann added a comment - @ Robin Jansohn : Our build process generates a .war file of a certain code-base and changes the application.properties and the name and other configuration values according to a number of params we pass to that job. So the result are multiple applications of the same 'program', and they do not overwrite themselves. This works fine. We use the deploy plugin to put the war over to tomcat manager to install it... I supposed that the call to tomcat manager could be done parallel, because it is a web request, too. But it turns out, when we run concurrent builds, the plugin holds the later job until the first job is finished deploying. Hope I explained to better now.
          Hide
          jansohn Robin Jansohn added a comment -

          Anne Hartmann while this seems to make sense for your special workflow/job configuration (which seems to be heavily parameterized), I still see the problems mentioned in my first comment for normal concurrent builds. My main concern is that I'm not sure what the side effects are if we try to deploy the same context in parallel.

          If interest in this feature should increase we could think about adding an additional configuration option to switch between sequential and concurrent deployment. But as it currently stands this seems to be a very special edge case which IMHO does not merit a change of the plugin.

          As a workaround I would suggest taking a look at the job DSL plugin to simply create individual jobs for every application you want to deploy in parallel. This would probably also improve the traceability of your build environment in general.

          Show
          jansohn Robin Jansohn added a comment - Anne Hartmann while this seems to make sense for your special workflow/job configuration (which seems to be heavily parameterized), I still see the problems mentioned in my first comment for normal concurrent builds. My main concern is that I'm not sure what the side effects are if we try to deploy the same context in parallel. If interest in this feature should increase we could think about adding an additional configuration option to switch between sequential and concurrent deployment. But as it currently stands this seems to be a very special edge case which IMHO does not merit a change of the plugin. As a workaround I would suggest taking a look at the job DSL plugin to simply create individual jobs for every application you want to deploy in parallel. This would probably also improve the traceability of your build environment in general.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            anh1979 Anne Hartmann
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: