Closed mszalbach closed 1 year ago
rarkins
commented
1 year ago That seems unlikely based on this diff: https://app.renovatebot.com/package-diff?name=renovate&from=34.102.5&to=34.102.6.
Please:
mszalbach
commented
1 year ago 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. Maybe you have some tips what else I can try or enable to have some more insights.
rarkins
commented
1 year ago It looks like you changed your description about affected version too? Are you able to retry until you pinpoint it?
rarkins
commented
1 year ago 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
mszalbach
commented
1 year ago I am not sure if I did some error writing it down but my tests has the following results:
Version 34.100.2 fast Version 34.101.0 fast Version 34.102.0 fast Version 34.102.5 fast Version 34.102.6 slow Version 34.102.7 slow Version 34.106.0 slow
mszalbach
commented
1 year ago I also created an example on github against a fork of a Glassfish Repository (https://github.com/mszalbach/glassfish). If you wish I can also upload the docker compose and Renovate config I used.
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.
mszalbach
commented
1 year ago 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.
rarkins
commented
1 year ago I still can't believe my eyes, but somehow this seems caused by prettier update from 2.8.1 to 2.8.2 (and not by the type changes related to that update).
I get slowness on the latest commit when running like this:
RENOVATE_REPOSITORY_CACHE=reset yarn start --dry-run=extract renovatebot/renovate
DEBUG: Repository timing splits (milliseconds) (repository=renovatebot/renovate)
"splits": {"init": 8044, "extract": 14854},
"total": 23052If I downgrade prettier, I get:
DEBUG: Repository timing splits (milliseconds) (repository=renovatebot/renovate)
"splits": {"init": 11294, "extract": 2863},
"total": 14289(I suggest ignore init, it's mainly git and may fluctuate a little).
viceice
commented
1 year ago confirmed
viceice
commented
1 year ago disable prettier import speeds up too
viceice
commented
1 year ago here's the changes of prettier: https://github.com/prettier/prettier/compare/2.8.1...2.8.2
rarkins
commented
1 year ago mszalbach
commented
1 year ago Thanks a lot for the fast replies and the fast fix.
rarkins
commented
1 year ago Thanks for reporting! Once it's built, can you confirm it fixes things from your side?
mszalbach
commented
1 year ago Of course I will test it and will give you guys feedback, no later than Monday.
renovate-release
commented
1 year ago :tada: This issue has been resolved in version 34.108.1 :tada:
The release is available on:
34.108.1Your semantic-release bot :package::rocket:
mszalbach
commented
1 year ago Tested with Release 34.108.5 and scan time is back to ~30 seconds like expected. So everything works fine, thanks a lot.
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
``` [2023-01-20T09:23:25.257Z] DEBUG: Using RE2 as regex engine [2023-01-20T09:23:29.453Z] DEBUG: Parsing configs [2023-01-20T09:23:29.453Z] DEBUG: Checking for config file in /usr/src/app/config.js [2023-01-20T09:23:29.453Z] DEBUG: File config [2023-01-20T09:23:29.453Z] "config": { [2023-01-20T09:23:29.453Z] "platform": "bitbucket-server", [2023-01-20T09:23:29.453Z] "endpoint": "https://git.ivu-ag.com", [2023-01-20T09:23:29.453Z] "onboardingConfig": {"extends": ["config:base"]}, [2023-01-20T09:23:29.453Z] "onboarding": true, [2023-01-20T09:23:29.453Z] "allowedPostUpgradeCommands": [".*"], [2023-01-20T09:23:29.453Z] "regexManagers": [ [2023-01-20T09:23:29.453Z] { [2023-01-20T09:23:29.453Z] "fileMatch": ["^\\.copier-version$"], [2023-01-20T09:23:29.453Z] "matchStrings": [ [2023-01-20T09:23:29.453Z] "\\s+(?Have you created a minimal reproduction repository?
No reproduction repository