Pour la gestion des information sensibles (clé ssh, nom de l'utilisateur sur le VPS…), j'utilise les variables CI/CD ¹ configurables via le menu Settings > CI/CD > Variables.

Dans mon script de déploiement, j'utilise les variables suivantes

Toutes ces variables sont déclarées comme Protected, c'est à dire qu'elle ne peuvent être utilisées que sur des branches protégées. Les 3 premières sont Masked, ce qui permet de ne pas les afficher dans les logs des jobs CI/CD lancés par gitlab. Il n'est techniquement pas possible de masquer la dernière³, il faut donc être prudent de ne pas l'exposer dans le script de déploiement.

⚠ Marquer des variables /Protected/ et /Masked/ ne garantie pas la sécurité
totale de celle-ci et vous devez rester en total contrôle de votre fichier
=.gitlab-ci.yaml= afin de vous assurer qu'il ne soit pas compromis et n'envoie
pas ces données à un serveur tiers par exemple.

ℹ Il est possible d'utiliser un service externe pour la gestion des
secrets[fn:4]. Pour des raisons de simplicité, je ne me suis pas penché sur la
question mais ça peut être une alternative intéressante aux variables CI/CD.

Ce fichier⁴ permet de définir des jobs à exécuter par la pipeline CI/CD de gitlab. En l'occurrence, je m'en sers pour générer le site via Emacs et le déployer sur mon VPS. Ici, je commente le fichier que j'utilise pour déployer ce site que vous pourrez trouver à cette adresse (le fichier est susceptible d'avoir changé entre temps).

image: iquiw/alpine-emacs

J'utilise une image toute prête avec Emacs déjà installé pour gagner du temps.

stages:
  - deploy

J'utilise une seul étape que j'appelle deploy pour construire le site et le déployer sur mon VPS. Je pourrai le faire en deux étapes, build puis deploy mais vu la simplicité du script, je ne trouve pas nécessaire de faire cette distinction pour l'instant.

deploy:
  before_script:
    - 'command -v ssh-agent >/dev/null || ( apk add openssh-client-default )'
    - mkdir -p ~/.ssh
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - ssh-keyscan $DEPLOY_SERVER_IP > ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts

Dans la section before_script, je prépare la configuration ssh qui me permettra de déployer les fichiers générés sur mon VPS. Ici, on peut voir l'utilisation des variables CI/CD SSH_PRIVATE_KEY et DEPLOY_SERVER_IP. On peut voir que non seulement ces variables sont très pratiques mais également que leur utilisation est des plus simple. Elles s'utilisent comme des variables dans un script bash par exemple.

stage: "deploy"

Ici on décrit l'étape que représente cette section

script:
  - emacs --batch --no-init-file --load publish.el --funcall org-publish-all
  - ls -Al public
  - scp -r ./public/* $DEPLOY_SERVER_USER@$DEPLOY_SERVER_IP:$DEPLOY_SERVER_PATH

Le script de déploiement consiste simplement à générer le site avec Emacs en mode batch, puis de déployer les fichiers générés dans le dossier public sur le serveur distant. Mon approche utilise simplement scp pour l'instant mais il serait peut être plus judicieux de se pencher sur rsync pour cette tâche. Cette question se posera quand beaucoup de fichiers seront à synchroniser avec le serveur.

artifacts:
  paths:
    - public
only:
  - master

Le script génère un dossier public que l'on sauvegarde comme artefacts de notre job, ce qui permettra de consulter les fichiers générés via l'interface gitlab. On veut également que le job ne soit lancé que sur la branche master.

J'espère que les informations dans ce document sont suffisantes pour déployer simplement des fichiers vers un serveur grâce à gitlab. J'essaierai de tenir ce fichier à jour si je découvre des choses à force d'utilisation ou si la configuration change beaucoup avec le temps.

Malheureusement, depuis quelques temps, pour pouvoir utiliser les fonctionnalités de CI/CD proposées par gitlab sur des nouveaux projets, il faut lier une carte bancaire à son compte gitlab (valable pour l'instance gitlab.com). Nous pouvons remercier les mineurs de crypto qui profitaient du temps CPU gratuit offerts par cette fonctionnalité 👍. La carte n'est pas débitée mais ça reste une barrière à l'entrée qui peut en rebuter certains.