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

wait/notify steps

    XMLWordPrintable

Details

    Description

      waitUntil (JENKINS-25570) is useful when you need to poll for some external result. But there are cases where direct notification of a state change is possible, and this is more efficient than repeatedly polling. So there should be a wait step, probably with an optional timeout.

      One use case is for a flow to await an event notification from an external system. To support this it would probably suffice to have an UnprotectedRootAction endpoint accepting POST requests (or even GET, for convenience); like /git/notifyCommit and similar endpoints, the event would be advisory, so the flow would need to verify that the event really took place:

      while (externalSystemNotReady()) {wait()}
      

      Alternately/additionally, the endpoint could require a specific event ID, request authentication, accept a (JSON?) payload, etc. You can use input for such purposes, but this is focused on human interaction, rather than REST calls from another mechanical system.

      Another use case, which might be different enough to warrant a distinct step, is for one branch of a flow to notify another branch that some condition has been met and that it is safe to proceed; a kind of semaphore. This could serve as a generic alternative to JENKINS-26052 (fork/join):

      def done = [:]
      parallel a: {
        // do prep work A
        done.a = true
        notify() // wake up all waiters
      }, b: {
        // do prep work B
        done.b = true
        notify()
      }, c: {
        // do prep work C
        done.c = true
        notify()
      }, d: {
        while (!(done.a && done.b)) {wait()}
        // do later work D
      }, e: {
        while (!(done.b && done.c)) {wait()}
        // do later work E
      }
      

      Here the D branch could start as soon as A and B are finished even while C is running, whereas E could start as soon as B and C are finished even if A is taking longer, etc. You can already write

        waitUntil {done.a && done.b}
      

      but a direct notification is preferable.

      In order to support complex orchestrations, it would be desirable for notify to work across builds of a single flow, and across distinct flows in the system (assuming there is some way of communicating current state). It would even be useful to be able to support cross-master notifications, which is where this use case blends into the first.

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            Cross-job notifications could use JENKINS-32982.

            jglick Jesse Glick added a comment - Cross-job notifications could use JENKINS-32982 .
            jglick Jesse Glick added a comment -

            mtadeunet is there some reason you assigned this to yourself?

            jglick Jesse Glick added a comment - mtadeunet is there some reason you assigned this to yourself?
            jglick Jesse Glick added a comment -

            The webhook-step plugin seems to implement one of these use cases.

            jglick Jesse Glick added a comment - The webhook-step plugin seems to implement one of these use cases.
            jglick Jesse Glick added a comment -

            See workflow-basic-steps #98 for an example of the semaphore use case.

            jglick Jesse Glick added a comment - See workflow-basic-steps #98 for an example of the semaphore use case.

            People

              Unassigned Unassigned
              jglick Jesse Glick
              Votes:
              5 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

                Created:
                Updated: