Podczas zwykłej, mniej istotnej aktualizacji skrypty nie mogły przeprowadzić migracji z powodu tego, że baza danych jest na osobnym serwerze i jest ona w innej wersji niż standardowa w paczce debianowej (9.5.2 - 9.5.3).
Po odmowie działania przez skrypty aktualizacyjne wykonałem:
touch /etc/gitlab/skip-auto-migrations
i to pozwoliło zaktualizować pakiet debianowy do końca.
Następnie:
gitlab-ctl reconfigure
przeprowadziło migracje bazy danych itp. (przynajmniej tak twierdzi dokumentacja na stronie projektu).
Standardowo do aktualizacji służy:
gitlab-ctl upgrade
ale nie dawał sobie rady z kopią zapasową bazy danych.
Na koniec można przyrwócić domyślne działanie aktualizacji na przyszłość:
rm /etc/gitlab/skip-auto-migrations
Restart całego gitlaba wykonuje się przez:
gitlab-ctl restart
Do wszystkiego trzeba użyć sudo lub wykonywać polecenia jako root.
Standardowa ręczna procedura aktualizacji powinna wyglądać ponoć tak:
Najpierw trzeba zatrzymać aplikacje:
gitlab-ctl stop unicorn gitlab-ctl stop sidekiq gitlab-ctl stop nginx gitlab-rake gitlab:backup:create
Jeśli chcemy wykluczyć tworzenie kopii bazy danych:
gitlab-rake gitlab:backup:create SKIP=db
Potem zainstalować pakiet:
pkg -i gitlab_x.x.x-omnibus.xxx.deb
Potem dokonać migracji:
gitlab-ctl reconfigure gitlab-ctl restart
Czyli zmieściłem się prawie w standardowej procedurze.
AKTUALIZACJA:
Dla zewnętrznej bazy danych (postgresql na dedykowanym serwerze) należy wykonać:
ln -s /usr/bin/pg_dump /usr/bin/psql /opt/gitlab/bin/
by gitlab korzystał z dostępnej w systemie wersji pd_dump, zgodnej z wersją serwera, zamiast dostarczonej razem z gitlab-.