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?

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.

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.

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

jimklimov - 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.

Will this be usable outside of pipelines, or is it out of scope?

One of my projects is not using pipelines, but xml job configs.  Basically, we've got a bunch of jobs with:

   <builders>
     <hudson.tasks.Shell>
       <command>/bin/sh /some/script.sh ...</command>
     </hudson.tasks.Shell>
   </builders>

It would be nice to utilize an env var in that command to determine if the command is going to fail for the last time.

Nevermind.  I should have been looking into naginator plugin, which is what we actually use to trigger retries.