Some flows have a need to start some long-running branches where we do not really care about waiting for termination. They might be running informational tests that would not fail the main job, or sending notifications, etc. Using parallel for these is awkward because you have to put the entire remainder of the flow in another branch, which does not nest nicely, etc.

      Suggest an alternate fork {...} which runs some stuff in the background. Could return a Future-like object you could decide to wait on later if you wished. Possibly needed parameters:

      • A label, to be used as the thread name; perhaps optional, with some generated default.
      • A daemon flag. If off, there would be an implicit join at the end of the flow. If on, if the flow reaches the end and the thread is still running, it would be stop-ped (but we probably still need to wait for it to exit cleanly).

      There should be a bounding box for the fork that runs inside so that the exit from the block is contingent on every fork inside to terminate.

      Potentially this could allow parallel to be implemented as a library.

          [JENKINS-26052] Fork without join

          Jesse Glick created issue -
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-26034 [ JENKINS-26034 ]
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-26135 [ JENKINS-26135 ]

          Is this something you're working on currently or could I submit a pull request for this?

          Is this something that could be added to the 'support' module?

          Alexander Bertram added a comment - Is this something you're working on currently or could I submit a pull request for this? Is this something that could be added to the 'support' module?

          Jesse Glick added a comment -

          I do not think kohsuke is working on this currently. Pull requests are welcome in general but I would expect this to be one of the hardest things to implement in all of Workflow. You would need to understand in depth how the CPS engine works.

          Jesse Glick added a comment - I do not think kohsuke is working on this currently. Pull requests are welcome in general but I would expect this to be one of the hardest things to implement in all of Workflow. You would need to understand in depth how the CPS engine works.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-27127 [ JENKINS-27127 ]

          Martin d'Anjou added a comment - - edited

          Are you asking for a fork-join_none construct similar to the one in SystemVerilog?

          Martin d'Anjou added a comment - - edited Are you asking for a fork-join_none construct similar to the one in SystemVerilog ?

          Jesse Glick added a comment -

          Not really. There would be a bounding box, so all “threads” would still be joined at a predictable time. You would just get some more flexibility in expressing when to start each thread. Nothing you cannot do already, just a more convenient form for certain use cases.

          Jesse Glick added a comment - Not really. There would be a bounding box, so all “threads” would still be joined at a predictable time. You would just get some more flexibility in expressing when to start each thread. Nothing you cannot do already, just a more convenient form for certain use cases.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 160042 ] New: JNJira + In-Review [ 180228 ]
          Andrew Bayer made changes -
          Component/s New: pipeline-general [ 21692 ]

            kohsuke Kohsuke Kawaguchi
            jglick Jesse Glick
            Votes:
            7 Vote for this issue
            Watchers:
            13 Start watching this issue

              Created:
              Updated: