What does this MR do?
This MR changes the trending projects code so that data is precalculated, removing the need for any complex caching mechanisms (that didn't even work properly as discovered by @pacoguzman).
Are there points in the code the reviewer needs to double check?
The cronjob setup in particular needs a good pair of eyes to make sure I set it up properly.
@JobV: there's also a product related change in this merge request. Previously the list of trending projects was effectively infinite. In this MR however I have capped the list to the top 100 projects. This prevents us from storing a few million rows in the
trending_projects table. A 100 rows should be more than enough, but we can increase the limit if deemed necessary.
Why was this MR needed?
Caching of trending data didn't work properly, still leading to queries. Using caching in general would be very hard due to users being able to apply custom filters to the list of trending projects.
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
CHANGELOG entry added: this MR re-uses the previous CHANGELOG entry "Trending projects now only show public projects and the list of projects is cached for a day" for 8.13
Added for this feature/bug
All builds are passing
Conform by the merge request performance guides
Conform by the style guides
Branch has no merge conflicts with
master(if it does - rebase it please)
Squashed related commits together