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

Pipeline retry clause : expose the retry number

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When inside the `retry{}` clause, it may be useful to know which attempt number this is (e.g. to `archiveArtifacts` the debug logs under a uniquely named archive). Expose the retry number as a groovy and/or environment variable.

        Attachments

          Activity

          Hide
          abayer Andrew Bayer added a comment -

          So I can put this in the environment - of course, then it's "2", not 2 - i.e., a String, not an int. I'm trying to think if there's a way I can get around that and have it actually be an int but I don't think I'll be able to.

          What should the count be starting at? First attempt is 0, second attempt (a.k.a. the first retry) is 1, etc? Or first attempt is 1, second attempt is 2, etc?

          Show
          abayer Andrew Bayer added a comment - So I can put this in the environment - of course, then it's "2" , not 2 - i.e., a String , not an int . I'm trying to think if there's a way I can get around that and have it actually be an int but I don't think I'll be able to. What should the count be starting at? First attempt is 0, second attempt (a.k.a. the first retry) is 1, etc? Or first attempt is 1, second attempt is 2, etc?
          Hide
          abayer Andrew Bayer added a comment -

          Also, we could instead do something like env.RETRIES_REMAINING - that's actually simpler, since RetryStepExecution.Callback actually determines when to stop retrying based on counting down to 0 from the specified retry count, so I don't need to do any changes other than just dumping that into the environment.

          Show
          abayer Andrew Bayer added a comment - Also, we could instead do something like env.RETRIES_REMAINING - that's actually simpler, since RetryStepExecution.Callback actually determines when to stop retrying based on counting down to 0 from the specified retry count, so I don't need to do any changes other than just dumping that into the environment.
          Hide
          jimklimov Jim Klimov added a comment -

          I think the environment representation would be used in `sh` clauses and so shell script would take it into numeric consideration if needed. For groovy it can remain a number if that's easier.

          For starting value in my workaround, 1 was a starting value. Or actually, in the code it went like

          `script { def retrynum = 0; retry { try { retrynum++; ... } / catch...} }`

          So as the build step processing actually started, the value became 1.

          Show
          jimklimov Jim Klimov added a comment - I think the environment representation would be used in `sh` clauses and so shell script would take it into numeric consideration if needed. For groovy it can remain a number if that's easier. For starting value in my workaround, 1 was a starting value. Or actually, in the code it went like `script { def retrynum = 0; retry { try { retrynum++; ... } / catch...} }` So as the build step processing actually started, the value became 1.
          Hide
          jimklimov Jim Klimov added a comment -

          Yes, at least for unique naming - dumping a raw unique value is also good
          Even better if the same variable could be "defined" even if empty (or 0) when not inside a retry clause, so accessing it in any context is not an error

          Show
          jimklimov Jim Klimov added a comment - Yes, at least for unique naming - dumping a raw unique value is also good Even better if the same variable could be "defined" even if empty (or 0) when not inside a retry clause, so accessing it in any context is not an error
          Hide
          abayer Andrew Bayer added a comment -

          Jim Klimov - that's harder, annoyingly. I don't think I can do that outside of retry. But if you do something like if (env.RETRY_COUNT == null), that'll work fine. It's only if you try to do if (RETRY_COUNT ...) that you'll hit Groovy errors.

          Show
          abayer Andrew Bayer added a comment - Jim Klimov - that's harder, annoyingly. I don't think I can do that outside of retry . But if you do something like if (env.RETRY_COUNT == null) , that'll work fine. It's only if you try to do if (RETRY_COUNT ...) that you'll hit Groovy errors.

            People

            • Assignee:
              abayer Andrew Bayer
              Reporter:
              jimklimov Jim Klimov
            • Votes:
              4 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: