You can now specify the retries option for Declarative pipelines using either generic label selection or Kubernetes pod templates. However this must be opted into from every project—an administrator cannot set a general default policy to improve service availability.

      One option would be a GlobalConfiguration in pipeline-model-definition supplying a default for RetryableDeclarativeAgent.retries in all cases, or perhaps for a specific label.

      A Kubernetes-only option would be a nice field in KubernetesCloud giving a default for KubernetesDeclarativeAgent.retries.

      It is not really possible to define a default for Scripted Pipeline since use of the new system requires running the retry step.

          [JENKINS-70333] Default for Declarative agent retries

          Pablo added a comment -

          This is a great improvement, can't wait for this to be added!

          Pablo added a comment - This is a great improvement, can't wait for this to be added!

          Jesse Glick added a comment -

          mr_onion are you using Kubernetes agents, or something else?

          A KubernetesCloud-specific option would be quite straightforward to implement and arguably natural enough—along with API server endpoint, timeout configuration, and other infrastructural stuff, an administrator could decide that retries would be appropriate in this environment (for example because node pools are frequently upgraded, or because you are using AWS Spot instances).

          An option for any Declarative pipeline regardless of agent type would be less straightforward from a UX perspective. Should it apply to any agent? A specific label expression (or list of these)?

          (Either way, I guess a developer could explicitly configure retries 1 in a specific project that for whatever reason could not tolerate a retry.)

          Jesse Glick added a comment - mr_onion are you using Kubernetes agents, or something else? A KubernetesCloud -specific option would be quite straightforward to implement and arguably natural enough—along with API server endpoint, timeout configuration, and other infrastructural stuff, an administrator could decide that retries would be appropriate in this environment (for example because node pools are frequently upgraded, or because you are using AWS Spot instances). An option for any Declarative pipeline regardless of agent type would be less straightforward from a UX perspective. Should it apply to any agent? A specific label expression (or list of these)? (Either way, I guess a developer could explicitly configure retries 1 in a specific project that for whatever reason could not tolerate a retry.)

          Pablo added a comment - - edited

          jglick yep, im using Kubernetes agents that are AWS spot instances. 
          KubernetesCloudspecific option would be quite straightforward to implement and arguably natural enough -  I agree with that  

          Pablo added a comment - - edited jglick yep, im using Kubernetes agents that are AWS spot instances.  A  KubernetesCloudspecific option would be quite straightforward to implement and arguably natural enough -   I agree with that  

          Norbert added a comment -

          As far I understand, this is a reason why the example for a declarative pipeline from the documentation cannot work.

          Norbert added a comment - As far I understand, this is a reason why the example for a declarative pipeline from the documentation cannot work.

          Jesse Glick added a comment -

          norbert_wnuk no; the example works. This issue is about allowing every Declarative Pipeline to use retries without explicitly having to say so.

          Jesse Glick added a comment - norbert_wnuk no; the example works. This issue is about allowing every Declarative Pipeline to use retries without explicitly having to say so.

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

              Created:
              Updated: