-
New Feature
-
Resolution: Unresolved
-
Major
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.
- is duplicated by
-
JENKINS-36098 General purpose fire-and-forget command "wrapper" for Pipeline
- Resolved
- is related to
-
JENKINS-27127 wait/notify steps
- Open
-
JENKINS-26135 User-defined functions in git-global-lib
- Resolved
-
JENKINS-26034 Option to interrupt remaining branches when one branch fails
- Closed