Details

    • Similar Issues:

      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

            Hide
            jglick Jesse Glick added a comment -

            Cross-job notifications could use JENKINS-32982.

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

            Miguel Tadeu is there some reason you assigned this to yourself?

            Show
            jglick Jesse Glick added a comment - Miguel Tadeu is there some reason you assigned this to yourself?
            Hide
            jglick Jesse Glick added a comment -

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

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

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

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

              People

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

                Dates

                • Created:
                  Updated: