FS#70753 - [gitlab] RuntimeError: secrets.yml is a symlink

Attached to Project: Community Packages
Opened by Caleb Maclennan (alerque) - Saturday, 08 May 2021, 08:29 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 08 May 2021, 12:22 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The current arrangement with config files in `/etc` and necessary links from the `/usr` directories makes perfect sense to me, but Gitlab (at least as of a fresh install of 13.10.3) does not like this one:

> Unable to load application: RuntimeError: File \"/usr/share/webapps/gitlab/config/secrets.yml\" is a symlink that does not point to a valid file

I can't figure out how to make GitLab read this from the `/etc/webapps/gitlab` directory instead of the symlink.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 08 May 2021, 12:22 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#67173 
Comment by Caleb Maclennan (alerque) - Saturday, 08 May 2021, 09:46 GMT
This is a weird one. If I run `rake gitlab:backup:restore`, the gitlab-puma service will fail to start with the error above. But if I copy the file from /etc to /usr (overwriting the symlink), then Puma starts fine. So far as expected given the error. But then I can delete the copy of the config in /usr and put the symlink back and everything still works fine! I think this symlink check is only being run during some sort of first-run phase, perhaps while it updates some database keys or something. It does not attempt to write the config.yml file, my original one is fine. Once it does whatever else it does, it no longer cares if the config is symlinked.