Fork mode: finding the fork costs the fork token 2+ requests per repository, every run

[mbarbero]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

44.115.10

Please tell us more about your question or problem

I run Renovate in fork mode across many orgs. token is a GitHub App installation token (one per org). forkToken is a classic PAT of one bot user that owns all the forks. Each org's installation has its own budget of at least 5,000 requests/hour, but the fork token is one user's 5,000/hour, shared by every repository in every org.

In fork mode, initRepo calls findFork(forkToken, repository, forkOrg) for every repository on every run, even when there is nothing to update:

• listForks lists the upstream repository's forks with the fork token, 100 per page and up to 100 pages. A heavily forked repository can cost up to 100 requests.
• Unless the fork is found in forkOrg, getUserDetails(…, forkToken) calls GET /user to get the bot's login. The result isn't reused, so this happens once per repository.

So the fork token pays at least 2 REST requests per repository per run before any real work. With ~4,000 repositories checked hourly, that's at least 8,000 requests/hour against a 5,000/hour budget, while each org's installation budget stays mostly unused. (Clone, fetch and push also use the fork token, but git traffic isn't counted in the REST budget.)

1. List forks with the platform token instead of the fork token. Listing the upstream repository's forks only needs read access to it, which the platform token always has. When both tokens are the same PAT, nothing changes; with a GitHub App, the cost moves to that org's own installation budget.
2. Reuse the fork token's user details for the whole run, since the login doesn't change between repositories.
3. Optional: look up Renovate-created forks directly. createFork names them <owner>-_-<repo>, so GET /repos/<forkOwner>/<owner>-_-<repo> (checking parent.full_name) finds the fork in one request however many forks exist, falling back to listing forks when it isn't there.

With 1 and 2, a run with nothing to update makes no REST requests with the fork token at all. It is then only used for git, creating forks, and creating or updating PRs.

No config change. Behavior is identical when token and forkToken are the same PAT.

Related: #39263 (future of fork mode). I'm happy to open a PR for 1 and 2, and 3 if you think it's worth it.

Logs (if relevant)

No response

[mbarbero]

Any thoughts? I am aiming to follow the contributing guidelines by starting a discussion before submitting a PR, though I am open to a PR if maintainers prefer to discuss over some code. Thank you!