Section mise à jour mis à jour (aha).
This commit is contained in:
parent
f856db9728
commit
617ee6c7ef
|
@ -11,15 +11,15 @@ title: Howto GitLab
|
||||||
|
|
||||||
Nous installons la version **10** sous **Debian 9** (Stretch) avec une approche multi-instances.
|
Nous installons la version **10** sous **Debian 9** (Stretch) avec une approche multi-instances.
|
||||||
|
|
||||||
GitLab s'appuie sur Git, Ruby, Go, NodeJS, PostgreSQL et Redis.
|
GitLab s'appuie sur Git, Ruby, Go, Nginx, NodeJS, PostgreSQL et Redis.
|
||||||
|
|
||||||
> **Note** : dans les exemples ci-dessous, on va créer une instance nommée *foo*
|
> **Note** : dans les exemples ci-dessous, on va créer une instance nommée *foo*
|
||||||
|
|
||||||
## Dépendances
|
## Dépendances
|
||||||
|
|
||||||
GitLab nécessite des versions très récentes de Git, Ruby, Go et NodeJS.
|
GitLab nécessite des versions très récentes de Git, Ruby, Go, NginX et NodeJS.
|
||||||
|
|
||||||
On utilise des versions de Stretch Backports pourt Git et Go via un « pinning » APT :
|
On utilise des versions de Stretch Backports pourt Git, Go et NginX via un « pinning » APT :
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
Package: *
|
Package: *
|
||||||
|
@ -439,10 +439,11 @@ Attention, le fichier `secrets.yml` contient les clés de chiffrements pour les
|
||||||
# Mises à jour
|
# Mises à jour
|
||||||
|
|
||||||
Le principe des mises à jour est basé sur un `git pull` et un `git checkout`.
|
Le principe des mises à jour est basé sur un `git pull` et un `git checkout`.
|
||||||
|
Ensemble de [scripts](https://forge.evolix.org/projects/evogitlab/repository) que l'on utilise. La procédure manuelle ci-après n'est peut-être pas à jour.
|
||||||
|
|
||||||
## Mise à jour mineure 9.a.b vers 9.c.d.
|
## Mise à jour mineure 10.a.b vers 10.c.d.
|
||||||
|
|
||||||
Procédure générique. Il est possible de « sauter » plusieurs versions. Par exemple, de 9.0.7 à 9.1.4, etc.
|
Procédure générique. Il est possible de « sauter » plusieurs versions. Par exemple, de 10.0.7 à 10.1.4, etc.
|
||||||
|
|
||||||
### Sauvegarde
|
### Sauvegarde
|
||||||
|
|
||||||
|
@ -456,9 +457,10 @@ $ bundle exec rake gitlab:backup:create RAILS_ENV=production
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
$ umask 002
|
$ umask 002
|
||||||
$ git fetch --all
|
$ git fetch --all -p
|
||||||
$ git checkout -- Gemfile.lock db/schema.rb
|
$ git fetch -t
|
||||||
$ git checkout v9.x.y -b v9.x.y
|
$ git checkout -- Gemfile.lock db/schema.rb yarn.lock locale
|
||||||
|
$ git checkout -B v10.x.y tags/v10.x.y
|
||||||
$ sed -i -e s'/app_user="git"/app_user="foo"/' \
|
$ sed -i -e s'/app_user="git"/app_user="foo"/' \
|
||||||
-e 's/# Provides: .*gitlab$/# Provides: gitlab-foo/' \
|
-e 's/# Provides: .*gitlab$/# Provides: gitlab-foo/' \
|
||||||
lib/support/init.d/gitlab
|
lib/support/init.d/gitlab
|
||||||
|
@ -470,16 +472,29 @@ $ git commit -a -m 'change default user'
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
$ cd ~/gitlab-shell
|
$ cd ~/gitlab-shell
|
||||||
$ git fetch
|
$ git fetch --all
|
||||||
$ git checkout v$(cat ~/gitlab/GITLAB_SHELL_VERSION) -b v$(cat ~/gitlab/GITLAB_SHELL_VERSION
|
$ git checkout -B v$(cat ~/gitlab/GITLAB_SHELL_VERSION) tags/v$(cat ~/gitlab/GITLAB_SHELL_VERSION
|
||||||
|
$ bin/compile
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
### Mise à jour de gitlab-workhorse
|
### Mise à jour de gitlab-workhorse
|
||||||
|
|
||||||
~~~
|
~~~
|
||||||
$ cd ~/gitlab-workhorse
|
$ cd ~/gitlab-workhorse
|
||||||
$ git fetch
|
$ git fetch --all
|
||||||
$ git checkout v$(cat ~/gitlab/GITLAB_WORKHORSE_VERSION) -b v$(cat ~/gitlab/GITLAB_WORKHORSE_VERSION)
|
$ git checkout -B v$(cat ~/gitlab/GITLAB_WORKHORSE_VERSION) tags/v$(cat ~/gitlab/GITLAB_WORKHORSE_VERSION)
|
||||||
|
$ make
|
||||||
|
~~~
|
||||||
|
|
||||||
|
### Mise à jour de Gitaly
|
||||||
|
|
||||||
|
~~~
|
||||||
|
$ cd ~/gitaly
|
||||||
|
$ pkill -u gitaly
|
||||||
|
$ git fetch --all --tags
|
||||||
|
$ git checkout v$(<~/gitlab/GITALY_SERVER_VERSION)
|
||||||
|
$ cp config.toml{.example,}
|
||||||
|
$ sed -i "s#/home/git/#/home/${gitlabUser}/#g" config.toml
|
||||||
$ make
|
$ make
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
|
@ -490,9 +505,12 @@ $ cd ~/gitlab
|
||||||
$ bundle install --without development test mysql aws kerberos --deployment
|
$ bundle install --without development test mysql aws kerberos --deployment
|
||||||
$ bundle clean
|
$ bundle clean
|
||||||
$ bundle exec rake db:migrate RAILS_ENV=production
|
$ bundle exec rake db:migrate RAILS_ENV=production
|
||||||
|
$ git checkout -- package.json
|
||||||
|
$ yarn install
|
||||||
$ bundle exec rake yarn:install gitlab:assets:clean gitlab:assets:compile RAILS_ENV=production NODE_ENV=production
|
$ bundle exec rake yarn:install gitlab:assets:clean gitlab:assets:compile RAILS_ENV=production NODE_ENV=production
|
||||||
|
$ bundle exec rake gettext:compile RAILS_ENV=production
|
||||||
$ bundle exec rake cache:clear RAILS_ENV=production
|
$ bundle exec rake cache:clear RAILS_ENV=production
|
||||||
$ git commit -a -m 'upgraded to 9.x.y'
|
$ git commit -a -m 'upgraded to 10.x.y'
|
||||||
~~~
|
~~~
|
||||||
|
|
||||||
### Redémarrer GitLab
|
### Redémarrer GitLab
|
||||||
|
@ -514,12 +532,10 @@ Si tout est au vert, la migration s'est bien passée !
|
||||||
|
|
||||||
## Mise à jour majeure
|
## Mise à jour majeure
|
||||||
|
|
||||||
En attente d'une version majeure. À priori la 10.
|
C'est sensiblement la même chose mais il faudra merger des fichier de configurations pour appliquer des nouveaux paramètres.
|
||||||
|
|
||||||
# Divers / FAQ
|
# Divers / FAQ
|
||||||
|
|
||||||
Ensemble de [scripts](https://forge.evolix.org/projects/evogitlab/repository) que l'on utilise.
|
|
||||||
|
|
||||||
## Restaurer un backup vers un autre nom d'instance
|
## Restaurer un backup vers un autre nom d'instance
|
||||||
|
|
||||||
Si vous avez un backup de foo, que vous voulez restaurer dans bar, il faudra faire une restauration classique puis via psql :
|
Si vous avez un backup de foo, que vous voulez restaurer dans bar, il faudra faire une restauration classique puis via psql :
|
||||||
|
@ -541,26 +557,3 @@ Par exemple si on downgrade une version. Il faudra récupérer la bonne version
|
||||||
```
|
```
|
||||||
$ bundle exec rake db:migrate:redo RAILS_ENV=production VERSION=20161223034646
|
$ bundle exec rake db:migrate:redo RAILS_ENV=production VERSION=20161223034646
|
||||||
```
|
```
|
||||||
|
|
||||||
## Corriger l'erreur column timelogs.merge_request_id does not exist
|
|
||||||
|
|
||||||
Si vous avez une erreur 500 lors de l'accès à une merge request et l'erreur suivante dans les logs :
|
|
||||||
|
|
||||||
~~~
|
|
||||||
==> gitlab/log/production.log <==
|
|
||||||
Started GET "/foo/bar/merge_requests/1" for 2001:db8::f00 at 2017-06-19 09:48:11 +0200
|
|
||||||
Processing by Projects::MergeRequestsController#show as HTML
|
|
||||||
Parameters: {"namespace_id"=>"foo", "project_id"=>"bar", "id"=>"1"}
|
|
||||||
Completed 500 Internal Server Error in 214ms (ActiveRecord: 28.3ms)
|
|
||||||
|
|
||||||
ActionView::Template::Error (PG::UndefinedColumn: ERROR: column timelogs.merge_request_id does not exist
|
|
||||||
LINE 1: ...UM("timelogs"."time_spent") FROM "timelogs" WHERE "timelogs"...
|
|
||||||
~~~
|
|
||||||
|
|
||||||
C'est que le schéma SQL n'est pas à jour. Pour corriger le problème on peut jouer la migration DB qui s'occupe de crée la colonne timelogs.merge_request_id.
|
|
||||||
|
|
||||||
~~~
|
|
||||||
$ bundle exec rake db:migrate:redo RAILS_ENV=production VERSION=20170124174637
|
|
||||||
~~~
|
|
||||||
|
|
||||||
> **Note**: Si vous avez un erreur avec le redo, il faudra probablement éditer le fichier de migration, pour commenter la partie « down ».
|
|
Loading…
Reference in a new issue