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
-
-
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.
-
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.
-
Depuis la migration des dépôts du code de Drupal ainsi que de l'ensemble des modules tiers sur Gitlab, nous sommes nombreux à attendre que l'ensemble des possibilités offertes par ce changement soient accessibles.
-
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.
-
Le vendredi 3 avril Scaleway nous a fait une belle surprise, les instances C2x ne démarraient plus. Si vous avez une instance en fonctionnement, ne la coupez surtout pas, il y a de grandes chances que comme moi, vous ne puissiez plus la démarrer. Considérez de faire une migration sous peu !
-
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 -
Le jeudi 29 septembre le lavajug (Java User Group de Clermont-Ferrand) organisait une conférence présentée par Alain Hélaïli qui travaille chez GitHub.
La présentation concernait les méthodes de travail dans l’entreprise et le process de déploiement d’une nouvelle fonctionnalité sur github.com.
Si vous souhaitez voir la conférence :
-
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 :
-
Principe de base
Git via les « hooks » propose un moyen d’exécuter des actions personnalisées suite à des événements. Il existe différents hooks, chacun lancés à des moments différents, on peut noter par exemple les suivants :