HTTP 429 for renovate runs #2103
Labels
No labels
accessibility
bug
bug
infrastructure
Codeberg
contributions welcome
docs
duplicate
enhancement
infrastructure
legal
licence / ToS
please chill
we are volunteers
public relations
question
question
user support
s/Forgejo
s/Forgejo/migration
s/Pages
s/Weblate
s/Woodpecker
security
service
upstream
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Codeberg/Community#2103
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Comment
Hi all,
this is in response to https://social.anoxinon.de/@Codeberg/115074265437710727 (Limiting HTTP Clone).
I'm running renovate for my repositories (currently 15, but not all of them "active"), and since yesterday running into a 429 after processing the first few Repos:
Renovate is running inside a selfhosted forgejo runner (currently all runners are affected). I'm trying to cache, but it's currently not that easy (https://code.forgejo.org/forgejo/runner/issues/733)
Renovate currently uses an account-wide API Token to git clone using https.
Unfortunately, the renovate repo itself is currently not public yet (waiting for forgejo/forgejo#4308).
Details of the setup are also in forgejo/forgejo#8839
While I'll try to switch SSH, and don't see immediate action over here, I'd like to document the current effects here.
If possible, a more relaxed rate limit for "authenticated" clones (e.g. using api keys) would be nice of course.
Thanks!
Quick Update:
SSH Works better, but also fails consistently "mid pipeline" after a few repos (more than with HTTPS):
I currently see no easy workaround over here, because by design renovate does all repos it is configured for at once.
Hi, I'm sorry to hear that our rate-limits are causing issues. We have relaxed the HTTP timeouts several times. The current limit is around 50 repos / 30 minutes (150 requests, but each clone/pull can do more than one request).
I considered fine-tuning this to separate "clones" from "pulls" so that updates to existing repos are not counted. Would this help for your situation?
For SSH, one option would be to reuse the SSH connection. Something like this in the .ssh/config
could do the trick.
Same issue here: I've tried to migrate a total of 9 repos to codeberg, but running renovate twice in succession breaks not only renovate but all workflows across my repositories (as they cannot even checkout the code anymore).
This makes it impossible to debug issues with the renovate configuration and makes workflows extremely fragile at other times.
Would it help to configure renovate with different tokens for a subset of the repos each? Or are rate limits per ip address (I only have a single server for my self-hosted runners)
I've added the following to my pipeline:
Renovate is configured to use SSH (
"gitUrl": "ssh",
) - it works a bit better, but is obviously a "not so great" workaround.With the cache active, I think there is no "full clone" happening (didn't understood renovate there completly yet, because normally I'm nowhere near the 50 repos except maybe for checking tags of "internal" dependencies).
Of course, it would be better if there is no aggressive rate limit for authenticated/SSH sessions, but for now it is working at least twice within 10min for my amount of repos.