Using GitHub App authentication can lead to expiry

[jamietanna]

When using Renovate self-hosted, with a GitHub App, we're hitting credentials errors:

 WARN: Bad credentials - aborting (repository={org}/{repo})

In this case, we're using --autodiscover, on a GitHub organisation with ~2000 repos.

GitHub App Authentication expires after 1 hour (source).

It may also be helpful to handle the authentication in Renovate's Action itself, so in the case an error is detected, we can break out and handle this appropriately before re-starting.

[viceice]

i think this is out of scope for the action.

[jamietanna]

Could it be something we'd be able to bring into Renovate itself? We already know when it's an App (source, another), and would allow handling longer-lived executions.

Or are there any alternatives recommended by the team for splitting out the executions to fit within a time limit / to better parallelise?

[viceice]

use mend renovate on-premise

https://github.com/mend/renovate-on-prem

it's like the hosted app, but for self-hosting and it supports GitHub App auth.

[jamietanna]

Oh interesting, thanks! Nice to see it's a free license key too 👏

So I guess for folks using the GitHub Action when self-hosting, the solution is currently to try to avoid the 1 hour expiry, and if that's becoming too difficult, moving to the On-Premises runner?

[viceice]

yes, the action is for small usage only. for big orgs you should use the free on-prem.

benefits:

• GitHub App auth
• webhooks ( so direct checkbox reaction)
• has an integrated scheduler so all repos are evenly processed.

[jamietanna]

Great, thanks! Are there any rough guidelines for the size of infrastructure required for this? I.e. for 100 repos, use 4 vCPUs and 2GB RAM?

[rarkins]

In the production app we use m3.medium VMs which have 1VCPU and 3.75GB RAM. We use them because they also have a 4GB SSD built-in which I assume makes git operations faster but never tested to verify that assumption.

With repository cache enabled, those machines each process 50-100 repos each per hour, depending on how much work is done. e.g. in weekends when there's less open source releases and less commits in repos, it does higher, while on Monday mornings when people have the highest chance of processing PRs, we see more commits and therefore more work to do so less throughput.

We will continue to focus primarily on repository cache as our primary means for optimization. Would love to get your inputs and/or PRs in this area any time you can think of improvements as it seems you're already thinking along these lines.

[jamietanna]

Thanks very much! And to confirm those numbers are based on the hosted Renovate app (GitHub App, Web App)?

[rarkins]

Yes. I still hope that we can keep driving down the amount of processing required per repo, and therefore increase throughput. We have improved those figures ~50% in 2022 already

[viceice]

converted to discussion, as it's unrelated to the action