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

Add a time delay capability to the retry basic step

      dnusbaum suggested creating this ticket for an enhancement I am proposing to the retry basic step.

      The retry step is a great utility step, but adding the ability to add a time delay between retries would be great. It can be as basic as adding a fixed time delay as a property to the step or an extensible option that allows you to use different algorithms for the time delay (Fixed, incremental, exponential, random, random exponential.

      A pull request for the basic fixed implementation has already been created at https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/97. This allows the user to do something like 

      retry(count: 3, useRetryDelay: true, delay: 40, units: "SECONDS").
      

      If the more advanced implementation is desired, it has also been implemented (and can be added to the pull request. @basil suggested modeling the extensible solution of other existing APIs that do something like this and proposed looking at Tenacity. The algorithms currently implemented are fixed, random, incremental, exponential, random Exponential. This would allow the user to do something like: 

      retry(count: 3, useRetryDelay: true, delay: incremental(increment: 2, max: 10, min: 1, unit: 'SECONDS'))
      

      All of this while still remaining backwards compatible and supporting something as simple as: 

      retry(3)
      

       

       

       

          [JENKINS-59678] Add a time delay capability to the retry basic step

          João Pinto added a comment -

          dnusbaum is there anything that can be done to move this along?

          João Pinto added a comment - dnusbaum is there anything that can be done to move this along?

          João Pinto added a comment -

          jglick dnusbaum basil  carroll (pinging because you have recent activity in the workflow-basic-steps repo)
          There's been a PR open for this for nearly 2 years. Is this feature something that would be welcome in the workflow-basic-steps plugin? If so, how can we get this merged?

          João Pinto added a comment - jglick dnusbaum basil   carroll (pinging because you have recent activity in the workflow-basic-steps repo) There's been a PR open for this for nearly 2 years. Is this feature something that would be welcome in the workflow-basic-steps plugin? If so, how can we get this merged?

          Carroll Chiou added a comment - - edited

          At the very least I think this comment needs to be addressed? https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/97/files#r342948867

          Though I'm not sure if the author is still looking at this PR...

          Carroll Chiou added a comment - - edited At the very least I think this comment needs to be addressed? https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/97/files#r342948867 Though I'm not sure if the author is still looking at this PR...

          João Pinto added a comment -

          I took the liberty of creating a new PR based on the changes krotte1 did in his original PR.
          https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/153

          João Pinto added a comment - I took the liberty of creating a new PR based on the changes krotte1 did in his original PR. https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/153

          Devin Nusbaum added a comment -

          For what it's worth, I took a quick look at https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/153, and here are two high-level comments:

          • Maybe it would be better to create a new plugin that implements a single retryWithDelay (or whatever) step that has all of these new options? Everything we add or modify in workflow-basic-steps needs to be supported by the people who have access to maintain the core Pipeline plugins, and that group has very limited bandwidth these days. Also, changes to steps in this plugin affect a large number of existing users and Pipelines, so we need to be extra careful to avoid regressions.
          • If everyone thinks it makes the most sense for this to be a modification to the core retry step in workflow-basic-steps, I would just add one or maybe two of what seem like the most likely delay options to be used (e.g., exponential, fixed) in workflow-basic-steps, and then implement the rest of the delay options in a separate plugin using RetryDelay as an extension point. That way, if anyone wants to add new options in the future they can do so in that plugin rather than needing to change workflow-basic-steps, so that the barrier to entry is lower and it is easier to add new delay types or modify existing ones if necessary.

          Devin Nusbaum added a comment - For what it's worth, I took a quick look at https://github.com/jenkinsci/workflow-basic-steps-plugin/pull/153 , and here are two high-level comments: Maybe it would be better to create a new plugin that implements a single retryWithDelay (or whatever) step that has all of these new options? Everything we add or modify in workflow-basic-steps needs to be supported by the people who have access to maintain the core Pipeline plugins, and that group has very limited bandwidth these days. Also, changes to steps in this plugin affect a large number of existing users and Pipelines, so we need to be extra careful to avoid regressions. If everyone thinks it makes the most sense for this to be a modification to the core retry step in workflow-basic-steps , I would just add one or maybe two of what seem like the most likely delay options to be used (e.g.,  exponential , fixed ) in workflow-basic-steps , and then implement the rest of the delay options in a separate plugin using RetryDelay as an extension point. That way, if anyone wants to add new options in the future they can do so in that plugin rather than needing to change workflow-basic-steps , so that the barrier to entry is lower and it is easier to add new delay types or modify existing ones if necessary.

          João Pinto added a comment -

          If implementing this as a separate step in a separate plugin would be a more welcome change, I'm willing to take a shot at it.

          João Pinto added a comment - If implementing this as a separate step in a separate plugin would be a more welcome change, I'm willing to take a shot at it.

            krotte1 Kyle Rotte
            krotte1 Kyle Rotte
            Votes:
            13 Vote for this issue
            Watchers:
            14 Start watching this issue

              Created:
              Updated: