mirror of
https://github.com/podman-container-tools/podman.git
synced 2026-08-11 03:15:44 +00:00
8942e2dbda
Frequent but intermittently, the stale issue and PR locking workflow generates the error: ``` You have exceeded a secondary rate limit. Please wait a few minutes before you try again. If you reach out to GitHub Support for help, please include the request ID XYZ ``` According to upstream `dessant/lock-threads` issue 48, this seems to be coming from the GitHub side (bug/feature/limitation), since the action uses an official github API rate-limiting library. It's unlikely related to which style/syntax of github token is used, nor if the action is executed concurrently across multiple repos. According to the rate-limiting docs: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits it's possible the issue is caused due to an unknown aspect of the clause: ``` These secondary rate limits are subject to change without notice. You may also encounter a secondary rate limit for undisclosed reasons. ``` The same docs indicate Github Apps have enhanced rate-limits which scale with the org's repo count. Attempt to fix the intermittent failures by making use of a new, dedicated, org-specific, private "Stale Locking App" I recently created. This requires the addition of a new action to the workflow that obtains a short-lived token for passing to lock-threads. Note: Because both `vars.STALE_LOCKING_APP_ID` and `secrets.STALE_LOCKING_APP_PRIVATE_KEY` are defined at the containers-organization level, the Buildah and Skopeo re-use of this workflow should continue to function normally w/o change. Signed-off-by: Chris Evich <cevich@redhat.com> |
||
|---|---|---|
| .. | ||
| actions/check_cirrus_cron | ||
| ISSUE_TEMPLATE | ||
| workflows | ||
| issue-labeler.yml | ||
| ISSUE_TEMPLATE.md | ||
| labeler.yml | ||
| PULL_REQUEST_TEMPLATE.md | ||
| renovate.json5 | ||