Add support for retries

[Moser-ss]

This issue comes from this issue #42 (comment)

As a rule of thumb, in all code that works with the network, the network will always one day fail.
For that reason, it will be great to implement a retry logic inside of the action so that the requests made to the GitHub API have a retry logic.

Also, we can expose the retry parameters to the user.

  attempt_limit:
    description: Number of attempts
    required: false
    default: 2
  attempt_delay:
    description: A delay between attempts in ms
    required: false
    default: 0

[gr2m]

The retry should take rate limits into account (the retry-after response header). I would start out with an implementation that is not configurable, we have a lot of experience from building the https://github.com/octokit/plugin-retry.js and https://github.com/octokit/plugin-throttling.js for octokit. As stated in #42 (comment) we could just use @octokit/core with these plugins, but the bundle would grow quite a bit, and we would introduce a pretty big 3rd party dependency (Bottleneck) that has not been updated for over three years.

[Moser-ss]

Do you know which library to use for retries?
I was thinking of using p-retry. It has a good size and looks to have a good score from Snyk Advisor

[gr2m]

p-retry is great, but it in turn also uses https://github.com/tim-kos/node-retry, which is a great, battle-tested library, but also implements a lot of functionality we don't need.

If this becomes a blocker, we can just go ahead and make it work first, then make it better later. Using either the Octokit plugins together with introducing @octokit/core or p-retry is fine, up to you if you are interested in implementing this feature. Using Octokit's plugins will probably be easier if you want to implement both retries and account for GitHub's throttling best practices

[create-app-token-action-releaser]

🎉 This issue has been resolved in version 1.6.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀