Optimize readme fetching by changing the system of readme detection
Mostly based on the task from customer, It seems the current readme search logic is slow, and fragile to errors. Repositories that don't have readme do very expensive checks for over 30 files.
The current logic iterates over generate patterns of files and tries to search for such file inside the repository. In GIT case with a lot of BINARY big files it's very slow to call get_node('unknonw_readme_path')
IMHO the whole search for readme logic is flowed. Image there's no readme we have to iterate over 30-50 combinations to search for readme.
Customer reported that in his case opening summary page (in which renderer search is taking place) takes 30-50s !!
Plan to fix this is:
add renderer to per-repo-settings. It will allow to define what renderer each repository uses. Probably need some changes how we fetch the global renderers.
per repo renderer will allow to generate per-repo order of readmes.
added new option about readme generation to into global visual and per repo: visual, consisting of:
autodetect(based on renderer try to auto-detect like currently)
none(don't load any readmes),
<list_of_patterns>List in order of picked renderer either global, or local
Updated by Johannes Bornhold over 4 years ago
The issue itself got fixed in https://internal-code.rhodecode.com/rhodecode-enterprise-ce/pull-request/2647
The idea to make the readme detection configurable has been split out into https://issues.rhodecode.com/issues/4222