What does this MR do?
Modify the pages update process so that useful information is written to the
.update file, instead of just a random string
Are there points in the code the reviewer needs to double check?
I still need to reason through the concurrency aspects of this. Will we need an exclusive lock on updating this file? Forced in-order execution of jobs?
The performance impact of this is expected to be fairly limited. The file we write increases linearly in size as more custom domains are added. GitLab.com has around 20,000 domains at the moment, which equates to a 600KiB file: https://performance.gitlab.net/dashboard/db/pages?refresh=1m&orgId=1&from=now-90d&to=now
Why was this MR needed?
Currently, the pages daemon needs to read the
config.json file for a project before it can serve custom domains. For large installations, this amounts to many thousands of files, and it can take several minutes to read all of them. On startup, this causes 404 responses for domains until the background worker has completed at least one full run
domain -> project map in a single file allows us to load configuration at first request instead, improving the user experience
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
Changelog entry added, if necessary
API support added
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