-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
File match scan got slow since version #19937
Comments
That seems unlikely based on this diff: https://app.renovatebot.com/package-diff?name=renovate&from=34.102.5&to=34.102.6. Please:
|
Hi thanks for the reply I added the details which docker image I use and on which platforms I run. I have tested this by starting Renovate with different versions multiple times and and checked timestamps of logs and the overall runtime of the process, and the "durationMs" of Renovate, which all gets slower. From the release notes I would agree there is nothing remotely connected to this behavior. |
It looks like you changed your description about affected version too? Are you able to retry until you pinpoint it? |
I'm running some quick tests using Docker on my Mac and I can confirm I'm seeing very slow extract too. I'll try to pinpoint which release it is |
I am not sure if I did some error writing it down but my tests has the following results: Version 34.100.2 fast |
I also created an example on github against a fork of a Glassfish Repository (https://github.com/mszalbach/glassfish). With 34.106.0 it takes 1 minute+ for the first 12 file match. With the older versions I can scan this in 12 seconds. With smaller repos it is not so clear. |
Did some more tests with the Github platform and I would still say the breaking point was the release renovate/renovate:34.102.6 The image renovate/renovate:34.102.5 is faster. |
I still can't believe my eyes, but somehow this seems caused by I get slowness on the latest commit when running like this:
If I downgrade
(I suggest ignore |
disable prettier import speeds up too |
here's the changes of prettier: |
Thanks a lot for the fast replies and the fast fix. |
Thanks for reporting! Once it's built, can you confirm it fixes things from your side? |
Of course I will test it and will give you guys feedback, no later than Monday. |
🎉 This issue has been resolved in version 34.108.1 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Tested with Release 34.108.5 and scan time is back to ~30 seconds like expected. |
How are you running Renovate?
Self-hosted
If you're self-hosting Renovate, tell us what version of Renovate you run.
34.106.0
If you're self-hosting Renovate, select which platform you are using.
Renovate full image on Linux Docker against a Bitbucket Server
If you're self-hosting Renovate, tell us what version of the platform you run.
Renovate image: renovate/renovate:34.106.0
Docker version 20.10.23, build 7155243
BitbucketServer 7.13.7
Was this something which used to work for you, and then stopped?
It used to work, and then stopped
Describe the bug
Renovate got slow while scanning for file match. This change happend somewhere between version 34.100.2(trying to pinpoint the excact version) and 34.102.7. It is still slow with the version 34.106.0.
From Tests with github platform against a glassfish fork I would say the problem starts occuring with renovate/renovate:34.102.6
For a single project the time for all file match checks increased from around 30 seconds to 3 minutes.
Relevant debug logs
Logs
Have you created a minimal reproduction repository?
No reproduction repository
The text was updated successfully, but these errors were encountered: