[gitlab] Mise-à-jour de gitlab de la version 13 à 14

La mise à jour de gitlab de la version 13 à la version 14 ne s’est pas déroulée comme prévue, sinon je n’aurai pas écrit ce blog.

Ci-dessous les différentes étapes que j’ai suivies, pour arriver à mes fins.

Ne copier pas bêtement mes codes sans lire les messages d’erreurs durant la mise-à-jour sur votre machine. Lisez bien ce qui est marqué dans ces messages afin de pouvoir prendre les bonnes mesures pour réparer ce qui ne va pas.

Le problème que j’ai rencontré à commencé par une simple màj du système.

$ sudo apt upgrade
...
The following packages will be upgraded:
  gitlab-ee
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,013 MB of archives.
After this operation, 70.9 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
(Reading database ... 115405 files and directories currently installed.)
Preparing to unpack .../gitlab-ee_14.2.3-ee.0_amd64.deb ...
gitlab preinstall: It seems you are upgrading from major version 13 to major version 14.
gitlab preinstall: It is required to upgrade to the latest 14.0.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: error processing archive /var/cache/apt/archives/gitlab-ee_14.2.3-ee.0_amd64.deb (--unpack):
 new gitlab-ee package pre-installation script subprocess returned error exit status 1

Pour vérifier la version de gitlab,

$ grep gitlab /opt/gitlab/version-manifest.txt |head -n1
gitlab-ee 13.11.3

Le message d’erreur me dit qu’il faudrait installer la dernière version en 14.0.x  (gitlab-ee_14.0.9-ee.0_arm64.deb) dans un premier temps.

L’installation de ce packet se fait, en précisant la version à installer après le signe égale en relation à notre paquet.

$ sudo apt install gitlab-ee=14.0.9-ee.0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  gitlab-ee
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,001 MB of archives.
After this operation, 77.9 MB of additional disk space will be used.
Get:1 https://packages.gitlab.com/gitlab/gitlab-ee/debian buster/main amd64 gitlab-ee amd64 14.0.9-ee.0 [1,001 MB]
Fetched 1,001 MB in 44s (22.8 MB/s)                                                                                                                                                     
(Reading database ... 115405 files and directories currently installed.)
Preparing to unpack .../gitlab-ee_14.0.9-ee.0_amd64.deb ...
gitlab preinstall: It seems you are upgrading from major version 13 to major version 14.
gitlab preinstall: It is required to upgrade to the latest 13.12.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: error processing archive /var/cache/apt/archives/gitlab-ee_14.0.9-ee.0_amd64.deb (--unpack):
 new gitlab-ee package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/gitlab-ee_14.0.9-ee.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Même problème que précédement. Le système me demande d’installer la dernière version en 13.12.x, qui est gitlab-ee_13.12.8-ee.0_amd64.deb.

$ sudo apt install gitlab-ee=13.12.9-ee.0
...
Upgrade complete! If your GitLab server is misbehaving try running
  sudo gitlab-ctl restart
before anything else.
If you need to roll back to the previous version you can use the database
backup made during the upgrade (scroll up for the filename).

Puis,

$ sudo apt install gitlab-ee=14.0.9-ee.0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  gitlab-ee
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,001 MB of archives.
After this operation, 53.0 MB of additional disk space will be used.
(Reading database ... 116886 files and directories currently installed.)
Preparing to unpack .../gitlab-ee_14.0.9-ee.0_amd64.deb ...
* unicorn['worker_timeout'] has been deprecated since 13.10 and was removed in 14.0. Starting with GitLab 14.0, Unicorn is no longer supported and users must switch to Puma, following https://docs.gitlab.com/ee/administration/operations/puma.html.
* unicorn['worker_processes'] has been deprecated since 13.10 and was removed in 14.0. Starting with GitLab 14.0, Unicorn is no longer supported and users must switch to Puma, following
 https://docs.gitlab.com/ee/administration/operations/puma.html.
Deprecations found. Please correct them and try again.
dpkg: error processing archive /var/cache/apt/archives/gitlab-ee_14.0.9-ee.0_amd64.deb (--unpack):
 new gitlab-ee package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/gitlab-ee_14.0.9-ee.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

La màj vers la version 14.0.9 n’est pas possible, puisque l’utilisation de l’ancien serveur Web de gitlab (unicorn) est obsolète.

Pour désactiver l’ancien mode de serveur,

$ sudo cat /etc/gitlab/gitlab.rb | grep -e ^unicorn
unicorn['worker_timeout'] = 60
unicorn['worker_processes'] = 4

$ sudo sed -i "s/^unicorn/# unicorn/g" gitlab.rb

$ sudo gitlab-ctl reconfigure

$ sudo apt install gitlab-ee=14.0.9-ee.0

Et voilà, la dernière version de gitlab en 14.0.x est installée. Essayons de mettre à jour le système une nouvelle fois.

$ sudo apt upgrade 
...
Warnings:
The version of the running redis service is different than what is installed.
Please restart redis to start the new version.

sudo gitlab-ctl restart redis

The version of the running postgresql service is different than what is installed.
Please restart postgresql to start the new version.

sudo gitlab-ctl restart postgresql

Running handlers complete
Chef Infra Client failed. 19 resources updated in 01 minutes 46 seconds

Ben, faisons ce qu’on nous demande de faire

$ sudo gitlab-ctl restart redis
ok: run: redis: (pid 865) 1s

$ sudo gitlab-ctl restart postgresql
ok: run: postgresql: (pid 877) 0s

Puis,

$ sudo gitlab-ctl reconfigure
..
Running handlers:
There was an error running gitlab-ctl reconfigure:

rails_migration[gitlab-rails] (gitlab::database_migrations line 51) had an error: Mixlib::ShellOut::ShellCommandFailed: bash[migrate gitlab-rails database] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/resources/rails_migration.rb line 16) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of "bash"  "/tmp/chef-script20210902-890-17x6l1n" ----
STDOUT: rake aborted!
StandardError: An error has occurred, all later migrations canceled:

Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':	{:job_class_name=>"CopyColumnUsingBackgroundMigrationJob", :table_name=>"ci_stages", :column_name=>"id", :job_arguments=>[["id"], ["id_convert_to_bigint"]]}

Finalize it manualy by running

	sudo gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,ci_stages,id,'[["id"]\, ["id_convert_to_bigint"]]']

For more information, check the documentation

	https://docs.gitlab.com/ee/user/admin_area/monitoring/background_migrations.html#database-migrations-failing-because-of-batched-background-migration-not-finished
/opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:1129:in `ensure_batched_background_migration_is_finished'
/opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20210707210916_finalize_ci_stages_bigint_conversion.rb:13:in `up'
/opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:61:in `block (3 levels) in '
/opt/gitlab/embedded/bin/bundle:23:in `load'
/opt/gitlab/embedded/bin/bundle:23:in `

Encore une fois, faisons ce qu’on nous demande de faire.

$ sudo gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,ci_stages,id,'[["id"]\, ["id_convert_to_bigint"]]']
Done.

En lançant de nouveau la commande « gitlab-ctl reconfigure », on me demande de lancer la commande,

$ sudo gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,push_event_payloads,event_id,'[["event_id"]\, ["event_id_convert_to_bigint"]]']
Done.

$ sudo gitlab-ctl reconfigure
...
Running handlers:
Running handlers complete
Chef Infra Client finished, 9/585 resources updated in 01 minutes 20 seconds
gitlab Reconfigured

Et voilà, gitlab est maintenant à jour.

$ grep gitlab /opt/gitlab/version-manifest.txt
gitlab-ee 14.2.3
gitlab-config-template         14.2.3                                     
gitlab-cookbooks               14.2.3                                     
gitlab-ctl                     14.2.3                                     
gitlab-ctl-ee                  14.2.3                                     
gitlab-elasticsearch-indexer   v2.13.0                                    git:31d8f69fc3155cfb266d2d8828722bf25dc8f22e                              
gitlab-exporter                11.2.0                                     
gitlab-geo-psql                bc339ea21bdbb329263ad93788aaa428           
gitlab-healthcheck             90e6447aeead4a29ac9fffc15945ce6b           
gitlab-kas                     v14.2.2                                    git:2b22fa677a333d86c52cbc01d059b0f5a7d1f311                              
gitlab-pages                   v1.42.0                                    git:118a1252ada382e00e53d7ee7e57f059f0e31aba                              
gitlab-pg-ctl                  bcf1e38894e7acf21c429648b0176666           
gitlab-psql                    7e11364159031db0eb55867ad3d5713b           
gitlab-rails                   v14.2.3-ee                                 git:b5eea856ecaa112a6ca45a0a39adc7e370a0fc90                              
gitlab-redis-cli               8866b9c12e308342bc148a794f5cc166           
gitlab-scripts                 14.2.3                                     
gitlab-selinux                 14.2.3                                     
gitlab-shell                   v13.19.1                                   git:757aa7c0e0b8733c75c744f188b0136c1fe1830f                              
registry                       v3.7.0-gitlab                              git:af5f507f08f18178694282570330b9a4a75c8151

Sources

Upgrading from 13.12 to 14.0

[gitlab] Problème d’authentication

Il faut tout d’abord que je vous explique le contexte.

J’ai créé un serveur Gitlab, auquel j’y ai accès à partir d’une de mes machines virtuelles. Aussi, je viens de configurer mon ordinateur pour pouvoir accéder au même serveur.

Bien que j’ai rajouté ma clé dans Gitlab, la connection ne peut pas se faire et on me demande un mot de passe, qui sera automatiquement refusé.

~/.ssh$ ssh -vT git@192.168.0.192
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.192 [192.168.0.192] port 22.
debug1: Connection established.
debug1: identity file /home/USERNAME/.ssh/id_rsa type 0
debug1: identity file /home/USERNAME/.ssh/id_rsa-cert type -1
debug1: identity file /home/USERNAME/.ssh/id_dsa type -1
debug1: identity file /home/USERNAME/.ssh/id_dsa-cert type -1
debug1: identity file /home/USERNAME/.ssh/id_ecdsa type -1
debug1: identity file /home/USERNAME/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/USERNAME/.ssh/id_ed25519 type -1
debug1: identity file /home/USERNAME/.ssh/id_ed25519-cert type -1
debug1: identity file /home/USERNAME/.ssh/id_xmss type -1
debug1: identity file /home/USERNAME/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2
debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.192:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:W7NYUROE1EaZDZEggk77VTMDVsP9v1ZgaEnxBXciv9g
debug1: Host '192.168.0.192' is known and matches the ECDSA host key.
debug1: Found key in /home/USERNAME/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/USERNAME/.ssh/id_rsa RSA SHA256:Vt81kOf3GkvSvazonS+DrF1Bmyev85/w9SHD/2kIlgA agent
debug1: Will attempt key: /home/USERNAME/.ssh/id_dsa
debug1: Will attempt key: /home/USERNAME/.ssh/id_ecdsa
debug1: Will attempt key: /home/USERNAME/.ssh/id_ed25519
debug1: Will attempt key: /home/USERNAME/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/USERNAME/.ssh/id_rsa RSA SHA256:Vt81kOf3GkvSvazonS+DrF1Bmyev85/w9SHD/2kIlgA agent
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/USERNAME/.ssh/id_dsa
debug1: Trying private key: /home/USERNAME/.ssh/id_ecdsa
debug1: Trying private key: /home/USERNAME/.ssh/id_ed25519
debug1: Trying private key: /home/USERNAME/.ssh/id_xmss
debug1: Next authentication method: password
git@192.168.0.192's password:

D’après la documentation, si le mot de passe vous est demandé, c’est que quelque chose ne va pas.

If on Git clone you are prompted for a password like git@gitlab.com's password: something is wrong with your SSH setup.

Vu les informations de connection, je ne vois aucun problème avec l’authentication. En mettant à jour le serveur Gitlab, j’ai trouvé le coupable.

# apt update
Hit:1 http://security.debian.org/debian-security buster/updates InRelease
Hit:2 http://deb.debian.org/debian buster InRelease
Hit:3 http://deb.debian.org/debian buster-updates InRelease
Hit:4 http://deb.debian.org/debian buster-backports InRelease
Get:5 https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease [23.3 kB]
Err:5 https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
Fetched 23.3 kB in 4s (5,735 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
W: Failed to fetch https://packages.gitlab.com/gitlab/gitlab-ee/debian/dists/buster/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3F01618A51312F3F
W: Some index files failed to download. They have been ignored, or old ones used instead.

 

Le problème est du au fait qu’il n’y a pas de clé publique pour le dépot Git.

Pour résoudre le problème, il suffit d’utiliser la clé donnée dans le message d’erreur.

# gpg --keyserver keyserver.ubuntu.com --recv 3F01618A51312F3F
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 3F01618A51312F3F: public key "GitLab B.V. (package repository signing key) <packages@gitlab.com>" imported
gpg: Total number processed: 1
gpg: imported: 1

# gpg --export --armor 3F01618A51312F3F | sudo apt-key add -
OK

# apt update
Hit:1 http://deb.debian.org/debian buster InRelease
Hit:2 http://deb.debian.org/debian buster-updates InRelease
Hit:3 http://security.debian.org/debian-security buster/updates InRelease
Hit:4 http://deb.debian.org/debian buster-backports InRelease
Get:5 https://packages.gitlab.com/gitlab/gitlab-ee/debian buster InRelease [23.3 kB]
Fetched 23.3 kB in 2s (12.1 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.

Après la mise-à-jour réussit, je n’ai plus eu de problème d’authentification pour accéder on mon projet Git.

 

 

[gitLab] Installation et configuration

Monter un serveur gitLab n’est pas des plus compliqués. Et donc, pourquoi écrire ce blog?

Si je n’ai pas rencontré quelques soucis lors de la configuration du serveur, et que je suppose que les mêmes problèmes peuvent arriver à certains d’entre nous, je vais donc prendre la peine de documenter mon parcours afin que vous puissez avoir les bases pour affronter les mêmes difficultés que moi.

Ma configuration pour le serveur est toute simple puisque je vais monter un serveur gitLab en local, pour des besoins personnels.

 

I. Prérequis

En ce qui concerne le prérequis, je vous laisse le soin de consulter la documentation.

Je suis parti avec comme base, un Debian 10 (4Go de RAM, 4Go d’espace Swap et 1 CPU avec 2 coeurs).

$ hostnamectl
<!-- sortie tronquée -->
Virtualization: kvm
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-6-amd64
Architecture: x86-64
$ free -m
total used free shared buff/cache available
Mem: 3946 2825 154 75 966 925
Swap: 4095 3 4092
$ lscpu
<!-- sortie tronquée -->
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2

 

II. Installation

La page officielle de gitLab donne les ingrédients pour une installation réussie, cependent le site internet digitalocean donne plus de détails, avec toutes les étapes à suivre, pour chaque version d’Ubuntu.

Et c’est parti!

Côté serveur

Installer les paquets curl, openssh-server et ca-certificates.

$ sudo apt-get update
$ sudo apt-get install curl openssh-server ca-certificates

Vu que je n’ai pas besoin de m’envoyer des emails, je me suis passé de Posix.

$ curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

 

Si vous êtes curieux de voir le contenu de ce script, télécharger le dans un fichier temporaire avant de le lancer.

$ cd /tmp
$ curl -L0 https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh
$ less /tmp/script.deb.sh/
$ sudo chmod +x /tmp/script.deb.sh
$ sudo bash /tmp/script.deb.sh

 

L’installation de gitLab se fait avec la commande « apt install gitlab-ee », en précisant l’URL ou l’adresse IP du futur serveur gitLab.

$ sudo EXTERNAL_URL="https://addresse_ip_ou_fqdn" apt install gitlab-ee

Si par accident vous n’avez pas ajouté l’URL ou l’adresse IP lors de l’installation de gitLab, vous auriez droit à un message qui vous indiquera comment mettre à jour cette information pour que l’installation puisse se terminer.

Pour ce faire, accéder au fichier gitlab.rb, et y apporter les modifications nécessaires.

$ sudo vim /etc/gitlab/gitlab.rb

Faites une recherche avec le mot clé « external_url ».

Une fois les modifications apportées, lancer la reconfiguration de l’application gitlab.

$ sudo gitlab-ctl reconfigure

 

Vous pouvez ensuite vérifier la version des différentes applications utilisées par gitLab.

$ grep gitlab /opt/gitlab/version-manifest.txt

$ sudo gitlab-rake gitlab:env:info
<!-- sortie tronquée -->
GitLab information
Version: 12.3.4-ee
Revision: df61ca7110b
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 10.9

<!-- sortie tronquée -->
GitLab Shell
Version: 10.0.0
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Git: /opt/gitlab/embedded/bin/git

Côté client

Sur votre ordinateur, vérifier que les paquet openssh-client et git sont bien installé.

mon@ordi$ dpkg -l | grep ssh
ii  openssh-client                       1:7.9p1-10+deb10u1                  amd64        secure shell (SSH) client, for secure access to remote machines
mon@ordi$ git --version
git version 2.20.1

Si ce n’est pas le cas, faites le.

mon@ordi$ sudo apt-get install openssh-client
mon@ordi$ sudo apt install git

 

III. Configuration

Une fois l’installation terminée, ajouter votre clé publique dans votre profil sur gitLab, afin de pouvoir téléverser vos mise-à-jour via SSH.

Si vous ne savez pas encore comment le faire pour créer une paire de clé dans Linux, je vous redirige vers mon article « Sécuriser votre RPi« .

Côté client

Générer une paire de clés avec l’utilitaire SSH keygen.

mon@ordi$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/matakasi/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Copier ensuite la clé publique.

mon@ordi$ cat ~/.ssh/id_rsa.pub

Côté serveur

Copier la clé dans l’espace dédié à votre utilisateur.

 

IV. Création d’un nouveau projet

Tout d’abord, je ne suis pas du tout familier avec gitLab. Par contre, comme je suis en train d’apprende à coder en JavaScript, gitLab est un très bon outil pour voir la progression de mon code avec le temps.

J’y vais donc en tatonnant.

Je ne me poste pas plus de question à ce moment. Je me lance avec la création du mon tout premier projet via la page d’acceuil.

La même chose peut se faire directement en ligne de commande à partir de la machine qui contient votre projet. Voir un plus bas.

Le projet sur gitLab enfin créé, j’ai suivi les instructions d’une vidéo youtube, afin de le mettre en parallèle avec les instructions de la page officielles de gitLab pour mieux comprendre ce qu’il faut faire pour la suite.

Configuration de l’utilisateur git.

mon@ordi$ git config --global user.name "VOTRE_NOM"
mon@ordi$ git config --global user.email "VOTRE_ADRESSE_EMAIL"
mon@ordi$ git config --global --list

Si vous ne souhaitez pas exposer votre adresse email, utiliser « votre_compte@noreply.gitlab.com ».

Initialiser le dossier local, qui sera votre dossier de travail, lequel sera envoyé dans gitLab.

Dans mon cas, je travaille sur un projet de site internet, mon dossier de travail se trouve dans /var/www/html.

mon@ordi$ cd /var/www/html
mon@ordi$ ls -l /var/www
drwxr-xr-x 3 NOM_UTILISATEUR www-data 4096 Oct 27 21:31 html

Pour changer le nom et le groupe associé au dossier html,

mon@ordi$ sudo chown -R NOM_UTILISATEUR:www-data /var/www/html/

Lancer « git init », qui va créer un dossier caché .git dans votre répertoire de travail.

mon@ordi$ git init

Si vous n’avez pas encore créé votre projet, vous pouvez le faire aussi en ligne de commande. Par contre, git ne peut créer la nouvelle branche une fois qu’après avoir initialisé un premier changement.

Sinon vous aurez droit à un message du type,

« error: src refspec master does not match any.
error: failed to push some refs« .

mon@ordi$ git add .
mon@ordi$ git commit -m "commit initial"
mon@ordi$ git remote add origin git@ip_ou_fqdn:NOM_GITLAB/PROJET.git
mon@ordi$ git push --set-upstream git@addresse_ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git master

Pour vérifier vos accès à votre projet dans gitLab,

mon@ordi$ git remote -v
origin git@ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git (fetch) origin git@ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git (push)

Si vous n’avez pas le bon « repository » et que vous souhaitez le supprimer, afin de le replacer la bonne addresse.

mon@ordi$ git remote rm orign

V. Valider vos modifications, puis les envoyer sur gitLab

Vous pouvez envoyer tout le dossier sur gitLab

mon@ordi$ git add .
mon@ordi$ git commit -m "VOTRE COMMENTAIRE"

Ou, juste les fichiers sur lesquels vous avez travaillés.

mon@ordi$ git add "nom_du_fichier-ou-non_du_dossier"
mon@ordi$ git commit -m "VOTRE COMMENTAIRE"

Ensuite,

mon@ordi$ git push origin master

Ici, il n’y a qu’une seule branche « master ». Autrement, la commande devrait inclure le nom de la branche.

mon@ordi$ git push origin <nom-de-la-branche>

Et là, le drame arrive à grand coup de sabot. Les modifications ne peuvent pas être envoyées sur gitLab.

Dans un premier temps, puisque je n’ai pas mis ma clé publique dans le projet gitLab, la commande push me demande de rentrer un mot de passe, qui sera refusé par la connection puisqu’il s’attend à recevoir une clé.

Rappeler vous que dans le projet, il vous est demandé de mettre une clé.

Une fois la clé ajoutée au projet, vous pouvez vérifier l’état de l’autentification à partir de votre machine.

mon@ordi$ ssh -T git@ip_ou_fqdn
mon@ordi$ ssh -vT git@ip_ou_fqdn

Si tout est bon, lancer une nouvelle fois la commande push. Et là, encore une fois, une nouvelle erreur.

« Updates were rejected because the tip of your current branch is behind its remote counterpart« .

Ce qui est tout à fait normal puisque, rappellez-vous, j’ai créé le projet directement sur github. En le faisant, dans le nouveau projet a été ajouté un fichier README que j’ai n’ai pas dans mon dossier local. Avec du recul, et après avoir bien étudié la question, j’aurai du cloner mon projet localement avant de la « push-er » dans gitLab.

mon@ordi$ git clone git@ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git

Je n’ai pas pu vérifier si c’était ce qu’il fallait faire. Je suis passé par une autre commande.

 

Alors, c’est parti avec une méthode assez barbarbe, genre « je ne sais pas ce que je fais, mais j’essaie quand même ».

mon@ordi$ git pull origin master
From ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET * branch master -> FETCH_HEAD 
fatal: refusing to merge unrelated histories
mon@ordi$ git pull --allow-unrelated-histories 
There is no tracking information for the current branch. 
<!-- sortie tronquée -->
mon@ordi$ git branch --set-upstream-to=origin/master master 
Branch 'master' set up to track remote branch 'master' from 'origin'.
mon@ordi$ git pull origin master From ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET 
* branch master -> FETCH_HEAD
fatal: refusing to merge unrelated histories
mon@ordi$ git push origin master To ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git 
! [rejected] master -> master (non-fast-forward) 
error: failed to push some refs to 'git@ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git' 
hint: Updates were rejected because the tip of your current branch is behind 
hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') 
before pushing again. 
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
mon@ordi$ git branch --set-upstream-to=origin/master master 
Branch 'master' set up to track remote branch 'master' from 'origin'.
mon@ordi$ git pull origin master From ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET 
* branch master -> FETCH_HEAD 
fatal: refusing to merge unrelated histories
mon@ordi$ git pull --allow-unrelated-histories 
Merge made by the 'recursive' strategy. 
README.md | 2 ++ 1 file changed, 2 insertions(+) 
create mode 100644 README.md

Après plusieurs tentative, on y arrive à nos fins.

mon@ordi$ git pull --allow-unrelated-histories
Already up to date.
mon@ordi$ git push origin master
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 4 threads
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 55.70 KiB | 1.64 MiB/s, done.
Total 9 (delta 1), reused 0 (delta 0)
To ip_ou_fqdn:VOTRE_NOM/VOTRE_PROJET.git
3019ea1..3f1d4cd master -> master
mon@ordi$

Une autre méthode aurait été de forcer la mise-à-jour avec l’option « -f ».

mon@ordi$ git push -f origin master

 

VI. Consommation excessive en mémoire

Une fois l’installation terminée, on peut constater l’usage excessive en RAM de gitLab.


Vu que c’est un nouveau projet, avec moi seul comme utilisateur, je ne trouve pas normal que l’utilisation de la mémoire est suppérieure à 90%, sur une RAM de 4Go. D’où leurs demande pour 8Go de mémoire pour ne pas avoir ce soucis.

Voilà ce qu’on obtient de htop.

En effectuant des recherches par-ci et par-là, j’ai trouvé quelques optimisations que l’on peut appliquer à gitLab.

$ sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak
$ sudo vim /etc/gitlab/gitlab.rb

Les voici, ces modifications.

$ sudo gitlab-ctl reconfigure

J’ai finalement pu réduire l’utilisation de la mémoire de moitiée pour quelques heures.

Après une journée de non utilisation, l’utilisation de la mémoire est remontée à 74%.

 

Sources

GitLab Installation
How To Install and Configure GitLab on Ubuntu 18.04
Adding a remote
Which remote URL should I use?
Start using Git on the command line
Start using Git on the comGithub “Updates were rejected because the remote contains work that you do not have”mand line
High memory usage for Gitlab CE
omnibus High memory usage for Gitlab CE
Reduce memory footprint of Gitlab CE
Introduction to the Git command line