-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rate limiting #35
Comments
You could edit the We could intergrate a tool like this to handle rate limiting in the future: https://github.com/octokit/plugin-throttling.js |
This is run daily, |
GitHub has some advice on how to actively handle the rate limit. Some options:
This would have to be done on the internal iterations in this package, so |
This cropped up for us as well on a relatively small issue/PR count repository:
The associated workflow configuration: name: 'Lock Threads'
on:
schedule:
- cron: '50 1 * * *'
jobs:
lock:
runs-on: ubuntu-latest
steps:
- uses: dessant/lock-threads@v3
with:
github-token: ${{ github.token }}
issue-comment: >
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
issue-inactive-days: '30'
pr-comment: >
I'm going to lock this pull request because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
pr-inactive-days: '30' Over in some of my personal and my work's GitHub Actions written in JavaScript, they utilize GitHub's NPM Package: https://www.npmjs.com/package/@octokit/plugin-throttling |
I'm getting daily errors now about the secondary rate limit. |
For me as well, any updates on this? |
It stopped being an issue for me when I spaced out other recurring actions. So not all actions at exactly midnight. Those other actions were also influencing the rate limit. Now, with everything an hour apart it works fine. |
I already spaced out all my recurring actions. |
I'm encountering this problem on a number of repos (all under one org.) that use this action once per day. Unfortunately the problem is also intermittent. Looking at the docs, I noticed this clause: "These secondary rate limits are subject to change without notice. You may also encounter a secondary rate limit for undisclosed reasons." 😞 Has spacing out the workflows resolved this issue for anybody else? |
Contrary to my earlier reply, spacing out my workflows stopped working. Or perhaps, I was simply lucky. |
Thanks for the reply, I was afraid of something like that 😞 Since there was actually a fix applied based on this issue, I think a new issue is warranted. |
This may be something we are experiencing based on the git commit history size of our repo or the amount of activity during our lock window, but this action is failing because it is exceeding github's rate limiting.
Can we slow this action down on it's usage of the github api to allow for larger/active repositories to function properly?
The text was updated successfully, but these errors were encountered: