Mutualiser les config de pipeline gitlab

Équipes maintenance
1

Bonjour tout le monde, et notamment @spip-maintenance

avec @marcimat on travail actuellement sur l’amélioration des pipelines d’Intégration Continue et de Deploiement continue) (CI/CD) Gitlab sur les dépots spip/* et spip-league/*.

Pour rappel, et en simplifiant, ces pipelines permettent notamment de s’assurer qu’une MR respectent un certain nombre de qualité de code par exemple :

  • style d’écriture
  • analyse statique
  • tests unitaires
  • etc.

On fait donc deux travaux avec @marcimat (sur le bac à sable).

  1. Ajouter des tests sur le respect du conventionnel commit, histoire de ne pas fusionner des MR qui ne respectent pas. Les premiers tests sont fructueux, mais @marcimat veut aller plus loin.
  2. Trouver une manière de configurer tout ces tests de manière globale pour l’ensemble des dépots spip/* et spip-league/*.

Je fais donc un petit point.

a. L’idée est d’avoir un composant ou plusieurs composant de CI que l’on peut appeler.
b. Les composants de CI peuvent soit être distribués sur le catalogue de Gitlab, soit disponibles uniquement en cherchant une forge/instance gitlab. C’est le second choix que j’ai retenu pour l’instant, car diminue le temps de maintenance.

Concrètement pour l’heure on a templates/spip.yml · 1.x · spip-league / gitlab-ci · GitLab qui reprend en gros tout ce qu’on avait dans ecrire, j’ai juste fait des ajustement pour avoir des noms de branches dynamiques (mais marcimat veut encore modifier des choses).

Et tout cela est appelé via une ligne dans .gitlab-cli.yml
exemple ici : change: on utilise la CI proposé par spip-league (!10) · Requêtes de fusion · spip-contrib-outils / bac_a_sable · GitLab

L’idée est donc qu’on appelle le composant spip sur la branche 1.x du dépot spip-league/gitlab-ci. En utilisant une logique de semantic versionning, on peut améliorer progressivement le processus d’intégration continue.

Avant d’aller plus loins

  1. Qu’en pense les autres ?
  2. Il faudrait sans doute ne pas avoir 1 seul composant, mais plusieurs composants, pour plus de modularité

Par ailleurs, si on continue sur cette perspective, il faudrait avoir des tests unitaire sur les composants (gitlab a un mécanisme pour cela).

A vous lire.

2
  1. que du bien !
  2. +1
3

la question est tout de meme de savoir si on envisage un compsant « minimal » qui inclus tout ce qu’on trouve nécessaire de toujours avoir.

4

Voilà un peu ce à quoi on est arrivé comme conclusion avec @marcimat

5