On 17/02/2020 06:30, john doe wrote:
On 2/16/2020 11:45 PM, Graham Seaman wrote:
Of course, though this would be easier if I was more sure where
everything was. But the data's no use without the software to read it.
https://docs.gitlab.com/ee/raketasks/backup_restore.html
Thanks - bit embarassing I didn't know that existed (I don't think there
was a backup option when I first installed it). But I've done pretty
much the same, but manually - rsyncing off the data files, psql_dump, etc.
Don't Gitlab has some kind of forum/mailing list?
Yes, it has many forums. I was just hoping someone working on the debian
side might pick up on this - the debian layout seems rather different
from the vanilla one(s), though maybe just because the version I had was
so old.
This will not help you for now but the following could be useful in the
future:
If you have VMs available, I would suggest you to have a clone of your
production "server" and to first on this VM how the upgrade process goes.
I hadn't thought of running a VM clone of the server - might be
generally useful. But the server's main jobs are as a router, firewall,
dnsmasq, mail server, which is where the main problems usually are in
upgrades, and I think it would be hard to duplicate the low-level comms
stuff meaningfully in a VM
Also, Gitlab seems overkill in your situation, if you need Git, simply
use the Git package and a frontend if you like.
Definitely. I think I might abandon gitlab and go with something much
simpler like gitweb. Ideally something I'm sure will be long-term
supported.
As I don't use Gitlab myself, that's all I can help you with.
Kind of you to reply as a non-gitlab user! Thanks.
Graham
--
John Doe
