J'ai présenté lors du Drupalcamp de Rennes en mars 2024 mon nouveau sideproject : un ensemble de jobs factorisés pour gitlab ci.
La problématique était la suivante :
Gitlab CI
-
-
Les rules de Gitlab CI permettent de définir quand doit, ou ne doit pas, être joué un job.
Retrouvez dans la ressource ci-dessous un paquet d'exemple avec des explications.
-
Les diapositives de la présentation : https://docs.google.com/presentation/d/1i0FZDAzQDJAidGSiyxdFbDD7oeaVh7Q…
Dépôt test / démo CI : https://gitlab.com/kgaut/drupal.kgaut.xyz
-
J'ai déjà expliqué précédement comment passer un job en fonction de fichier modifiés.
-
Je voulais pouvoir ne plus faire un backup de ma base de données, si mon message de commit contenait l'instruction "skip-db"
Voila le contenu de mon job :
-
Comme souvent quand je commence un support de formation, je passe (perd ?) du temps à modifier mon process pour gérer mes slides. Après un site drupal me permettant de gérer mes support, j'ai testé une nouvelle approche, plus véloce encore.
-
Pré-requis : connexion root sur le serveur gitlab installé via omnibus
-
Dans un job CI on peut cacher un fichier ou des dossiers résultant d'une commande, afin de le récupérer lors d'un prochain job.
-
Deuxième épisode de mes vidéos de mini-formations à Drupal avec au sujet du jour un point important : la gestion de la configuration dans Drupal.
Qu'est-ce que la configuration ? Comment l'exporter, l'importer, mais aussi et surtout comment, Ă l'aide du module config_split.
-
En ayant marre d'avoir à gérer x versions de de NodeJS sur ma machine avec pour chacune ses dépendances et incompatibilités, et de devoir se souvenir pour chaque projet quelle version utiliser, j'ai fini par externaliser cette gestion à docker, comme je le fais déjà depuis longtemps pour php, mysql, SolR...
-
Pour un projet, j'ai du mettre en place une stratégie de déploiement automatisée avec entre autres un déploiement sur un serveur de préproduction que lors de la création d'un tag preprod-x.x exemples : preprod-0.1, preprod-0.2, preprod-1.0...
-
Via Gitlab CI il est possible de faire qu'un job soit manuel (manual) afin que, comme son nom l'indique, il ne soit exécuté que si l'on en a besoin.
C'est pratique pour des tâches non obligatoires ou que l'on veut ne pas lancer à chaque déploiement.
-
Dans la version 13 de Gitlab CI qui sortira le 22/05/2020, les instructions only / exept ne fonctionneront plus dans nos fichiers .gitlab-ci.yml.
-
J’utilise énormément la partie « CI » de Gitlab pour déployer automatiquement les sites et applications web que je gère.
-
.gitlab-ci.yml
stages : - predeploy - deploy - postdeploy - scheduled prod_backup_db: script: - ssh <a href="mailto:user@serveur">user@serveur</a> 'drush @kg cr' - ssh <a href="mailto:u -
Si vous utilisez gitlab-ci pour mettre en place un déploiement automatisé vers votre serveur de production (ou n'importe quel type de serveur), Il faut que votre runner puisse s'authentifier via SSH sur le serveur.
Pour cela, on commence par lui créer une clé ssh :
-
Si vous tentez de mettre en place Gitlab CI sur votre serveur, au moment de l'enregistrement d'un runner, via la commande :