Impossible to use openid and stored secrets, with a pretty bad failure mode

The secrets.yml is force-generated from a bunch of env variables, even if it exists, but without variables for all content, making it impossible to set for example openid_connect_signing_key. What makes this situation much, much worse is that on first use, this variable is created by GitLab and written to the file. Then, GitLab will work perfectly fine with no complaints nor warnings, accepting your encrypted secrets. Until one day, you restart - and all that data will be lost, because on the next container start, the generated variable will be destroyed, making all your encrypted data inaccessible.

Lucky if you have a backup of the file - or are you ? Even if you backed up the key, you have no way to supply it, since the template simply doesn't contain the variable, and what's worse, you can't even mount the config file and put your variable in there manually, as it will get destroyed on each container restart!

This exact issue has been discussed in https://github.com/sameersbn/docker-gitlab/pull/2913 which was somehow changed for what seems unrelated reasons. As far as I can tell, that PR is absolutely perfect, with maybe the exception of containing an actual example key people could end up using, which would be trivially solved by replacing some lines in the middle of the example key with [...replace with your own key...]

Start by inspecting how secrets.yml is generated from environment variables, then compare that behavior with the proposed changes in pull request 2913. Verify the handling of openid_connect_signing_key across initial use and container restarts. Done means an existing or manually supplied signing key is preserved and can be used for encrypted secrets after a restart.