Closed Moser-ss closed 10 months ago
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 https://github.com/actions/create-github-app-token/issues/42#issuecomment-1781501122 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.
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
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
:tada: This issue has been resolved in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
This issue comes from this issue https://github.com/actions/create-github-app-token/issues/42#issuecomment-1783965170
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.