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 #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...]
The
secrets.ymlis force-generated from a bunch of env variables, even if it exists, but without variables for all content, making it impossible to set for exampleopenid_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 #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...]