Migration de la zone vers un Gitlab

Dev
1

Bonjour à toutes & tous, écureuils ébouriffés & polatouches soyeux,

En juillet dernier, quelques personnes s’étaient physiquement réunies dans un lieu magique pour bricoler et papoter sur SPIP.

Face à certaines limitations de la forge Gitea vis à vis l’intégration de librairies Composer dans Packagist et l’envie de mettre en place des outils d’intégration continue (CI), il avait été envisagé pour se faciliter grandement la tache, la maintenance et se concentrer sur du développement technique de SPIP de migrer l’organisation SPIP (spip/*, pas la zone) sur Github.

C’était quasiment acté, mais politiquement à contre-cœur pour certain·es personnes cependant.

Et cela ne s’est donc pas fait ; mais les mois s’écoulent et des problèmes subsistent sur la forge Gitea, particulièrement sur le dépot spip/spip qui nécessite alors des interventions d’Azerttyu. Les mises à jour de Gitea n’ayant à ce jour pas corrigé les difficultés rencontrées.

Azerttyu a demandé plusieurs fois de l’aide sur Gitea, mais il semble que peu de personnes soient à même de l’aider sur ce sujet dans notre communauté ;

Suite à ces différents points, considérant que nous fatiguons des problèmes réguliers sur Gitea, que nous souhaitons mettre en place des CI et qu’il semble difficile d’amener la communauté sur Github pour des raisons politiques, ni de séparer à nouveau le core de la zone, nous proposons de migrer SPIP et la Zone sur une instance Gitlab (gérée par Nursit).

Cela ne facilitera pas le point Composer => Packagist qui était l’une des raisons d’aller sur Github, mais ça devrait permettre, nous l’espérons, d’améliorer le fonctionnement général de notre forge, en allant vers un outil qui reste libre, et maîtrisé par un peu plus de personnes. Nous avons commencé quelques expérimentations en ce sens (côté Nursit, sur un serveur dédié).

Migrer une forge est un processus délicat et rempli de subtilités pour éviter de perdre certains contenus présents sur les dépôts, d’autant que l’import automatique de dépôts Gitea intégré dans Gitlab est insuffisant. Cela va nécessiter quelques expérimentations de migrations afin de valider que la migration prendra en charges tous les types de contenus (dépôts, tickets, pull requests, commentaires, approbations, etc.).

De plus, différents outils de SPIP s’appuient actuellement sur l’API de Gitea, qu’il faudra donc revoir également le moment venu.

Avez-vous des objections à cette migration ?

Voilà pour les news, on vous tient au courant des avancées et on vous fait signe dès qu’on a une version testable à vous proposer :slight_smile:

À vous lire,
b_b, cerdic, marcimat

8 « J'aime »
2

Hello

Merci pour ce chantier.

Modeste retour pour les gens que ne connaissent pas gitlab. Je l’utilise au quotidien et c’est du bonheur : c’est simple, robuste, industriel et sans rien gâcher très ergonomique. Bref pour l’usager c’est du bonheur en git :slight_smile:

3

Est-ce que les urls des dépôts resteront les même (en https: et en git:) ?

4
  • A priori oui, c’est un des objectifs.
  • Les mots de passe des utilisateur·ices ne sont pas migrés (il faudra donc faire un rappel de mot de passe a priori)
  • Les clés SSH des utlilisateur·ices sont migrées
  • Le ssh-agent va râler la première fois car l’ip du serveur ne sera pas la même.
1 « J'aime »
5

Alors c’est plus que les outils de SPIP. Le plugin Maintenance de Contrib qui motorise la structure de Contrib utilise l’API de Gitea mais les fonctions sont bien isolées dans une API.
Il faut juste espérer que l’on trouvera l’équivalent des requêtes actuelles.

Donc svp, un petit délai de prévenance serait apprécié.

Sinon, ça me va bien pour le switch même si on doit modifier des installations à la marge.

6

Bonjour

J’ai bon espoir que la question posée à la communauté ne soit pas juste rhétorique. J’ai et j’ai toujours eu des réserves concernant Gitlab, que je ne (re)détaillerai pas dans cette réponse. Je suis prêt à en rediscuter avec toutes les personnes parmi vous qui le souhaiteraient.

Concernant les limitations techniques exprimées (CI, packagist, …), quand cela a été abordé publiquement j’avais proposé des pistes de solutions à tester, je suis sans retour depuis.

Je trouve dommage de balayer ainsi le travail réalisé ces dernières années. Toutefois je ne peux que confirmer que, malgré mes efforts, mes nombreuses demandes d’aide à la communauté (et en direct auprès de certains de ses membres, qui s’en souviennent sûrement) sont restées sans réponse également.

C’est rare qu’un travail dit collaboratif aboutisse quand on le fait seul, je comprends donc les difficultés rencontrées par ceux qui ont pris cette décision. Passer sur un outil que Nursit utilise au quotidien dans son activité est sans doute préférable.

Logiquement, cela implique également la prise en charge (ou non) des outils suivants :

Vous noterez ma déception vis à vis de la façon dont cette décision a été prise et communiquée, et que j’apprends à peu près en même temps que vous.

Je reste bien entendu à disposition pour échanger avec la communauté.

1 « J'aime »
7

Merci Azerttyu pour cette réponse,

Il va de soi, et on te l’a dit auparavant par email, que nous sommes reconnaissants pour les années d’hébergements des services de la zone, l’investissement que tu as fourni dessus et pour la communauté SPIP et que nous espérons tu continueras à y consacrer et participer !

On a bien conscience de ta déception en quittant Gitea ; c’est un peu ton bébé ; mais il nous semble qu’aller vers un outil qui nous satisferait mieux et dont on a une plus grande confiance également, devrait nous apaiser quelque peu. Ce n’est pas vraiment balayer le travail réalisé non plus, qui a permis d’avancer jusque là dans l’aventure Git.

On comprend évidemment que cette proposition semble abrupte ; d’autant qu’une grande discussion bien tendue avait eu lieu en juillet dernier, mais qu’on n’avait pas trouvé la force de publier un compte rendu même très sommaire jusque là (:eyes: @b_b) !

Concernant les outils tierces, c’est à toi de nous dire si tu ne souhaites plus t’en occuper, nous pouvons reprendre ceux qui sont encore utilisés bien évidemment. Je pense pour ma part qu’on devrait pouvoir maintenant clôturer zone.spip.net et svn.spip.net , de même que latex & math amener sur une page qui indique d’aller utiliser le plugin mathjax à la place, qui corrige de nombreux points. Concernant le domaine spip.org je ne sais pas trop ce qui s’y trouve encore, mais si c’est quelques redirections d’email, ils devraient pouvoir se définir sur le registrar je présume…

Sur les autres points, pour Composer, pour le moment nous avons utilisé un dépôt spécifique créé avec Satis. Tant que le nombre de paquets spip/* reste limité, ça devrait tourner, mais il faudra peut être reconsidérer la chose ultérieurement. Pour les CI, j’ai bien vu que c’était passé stable chez Gitea très récemment, et donc qu’il y aurait eu moyen de le proposer à un moment… Cependant, on sait aussi que ce n’est pas trop compliqué à mettre en place sur Gitlab, et que ça y fonctionne bien.

Il va de soit que je nous souhaite le meilleur, à toi comme à la communauté autour de SPIP, et pouvoir continuer à maintenir SPIP sereinement.

Je sais ce que j’aimerais qu’il advienne pour SPIP 5 (mais je veux faire peur à personne ^^), mais je ne sais pas du tout si on y arrivera, il va falloir du temps, de l’énergie et de la motivation ; mais j’aimerais au moins qu’on continue d’essayer, pour que ce projet perdure par delà les vagues encore un peu !

Chaleureusement,

Matthieu.

2 « J'aime »
8

Oui, my bad, je m’en excuse (même si d’autres personnes personnes présentes auraient pu le faire aussi), mais perso je n’avais pas la l’envie de rédiger un compte rendu d’un moment tendu, c’est comme ça, j’aime pas le conflit. Et pour rappel, la discussion a été tendue non pas sur la migration de la forge, mais sur la question de supporter/adapter SVP à un SPIP full composer.

:two_hearts:

Les vagues on aime ça, on en redemande même ! ^^ /me =>

9

Pour discuter concrètement, on a fait une migration à blanc vers une forge gitlab.

En pratique :

  • tous les groupes sont migrés (mais pas leurs logos qu’il faudra remettre à la main)
  • tous les users ont été migrés avec leurs clés SSH (mais pas leurs mots de passe) et leurs projets persos, et leurs appartenances aux différents groupes spip
  • tous les projets de tous les groupes ont été migrés avec leur logos, Issues et PR, et sur chaque on a vérifié que chaque commentaire et réaction smiley était présente dans la version migrée sur gitlab. En pratique il manque 5 ou 6 PRs sur l’ensemble de la forge car elles sont en erreur 500 sur gitea et donc on ne peut plus avoir d’info dessus
  • tous les favoris de chaque utilisateurs sont récupérés aussi

La migration à blanc s’est déroulée sur la dernière semaine, donc les projets sont plus ou moins à jour sur le gitlab, mais ça c’est parce que on a migré pendant que tout le monde continuait à travailler.

On a pas migré les watch, car le système de notification de gitlab est différent, et chacun peut régler son niveau de notification par défaut (au global) puis projet par projet. On est réglé par défaut en notification en cas de participation.

Vous pouvez faire un rappel de mot de passe et vous connecter pour voir si vous retrouvez tout bien sur vos projets, ou explorer directement ici donc :

Pour une migration finale on scratcherait tous les projets et users et on rejouerait tout le script de migration qui est maintenant éprouvé. Il faudrait fermer la forge aux contributions pendant 2 jours environs le temps de migrer tout (c’est assez long car on passe sur les projets un par un et on vérifie tout)

5 « J'aime »
10

Notons qu’il reste au moins 1 point à corriger : remettre le lien de fork sur les projets forkés (c’est en cours d’analyse)

1 « J'aime »
11

Lors de la migration il faudra aussi bloquer les inscriptions sur Contrib car il va falloir que je regarde comment migrer de l’API Gitea vers celle de Gitlab avant de remettre en route le système.

12

Alors… pour l’instant on était parti pour faire différemment :

  • la forge est ouverte à l’inscription (logiquement y a un antispam, mais ça sera à vérifier)
  • tu acceptes tacitement la charte à l’inscription (il y a un petit texte qui l’indique sur le formulaire, mais c’est pas hyper visible, et en anglais actuellement — le lien amène sur un texte en français plus explicite).
  • le compte doit être validé par les admins de la forge (on reçoit un mail)
  • ça ouvre une fois validé l’accès à la forge, aux dépôts publics et aux commentaires.

Et ensuite pour les droits de commits, c’est certainement à rediscuter ; je ne suis pas hyper favorable à ce que ce soit ouvert à tous vents si les personnes viennent juste pour écrire ou commenter des tickets. Il y a la possibilité de demander à participer à une organisation (et donc aux commits) (sur l’organisation publique, […] → Request Access) ; par contre seuls les owner du group reçoivent une notification a priori ; à étudier) ; en tout cas on peut voir la liste des demandes sur l’interface).

Notes

  1. l’acceptation de la charte est bien plus claire avec les compte migrés que lors d’une nouvelle inscription
  2. il faut qu’on passe le Gitlab en français, c’est un oubli
  3. l’accès aux commits de toustes partout pourrait être rediscuté par ailleurs (c’est un point de vue personnel), car en terme de sécurité c’est limite… par exemple en désactivant les droits de commits des comptes qui n’ont pas commité depuis plus d’un an… et/ou en créant des d’autres groupes plus restreints pour certains projets avec des permissions différentes que «c’est open bar»… Il y a aussi du ménage à faire du côté de d’orga spip/ d’ailleurs.
13

C’est modifiable, avec une case à cocher obligatoire et explicite par exemple ?

Sinon, une remarque / question : les projets sont tous datés du moment de l’import apparemment, quand on trie par date de création ou de modification ça n’est plus informatif.
Je ne sais pas du tout sur quoi se base Gitlab, c’est quelque chose de gérable ?

14

Apparemment c’est prévu : Terms of Service and Privacy Policy | GitLab

Mais dans le cas d’une connexion avec Github ?

15

ah ouais j’allais le dire, je me suis bien connecté, tout marche pour ce que je vois, et je trouve ça pas mal le panneau pour accepter la charte avant de continuer (mais moi j’ai vu juste la version en ayant déjà un compte du coup)
mais faudrait que tout soit en français par défaut, et aussi fuseau horaire France

16

Bonjour

Parmi les régression je note le moteur de recherche sur l’ensemble du code de la forge.
Vous avez prévu quoi à ce propos ?

17

Ah bon… soit.
C’est toujours aussi cool de découvrir les trucs comme ça.

Alors ce qu’il faut faire c’est carrément supprimer maintenant le formulaire d’inscription sur Contrib ça évitera d’oublier le jour dit.
C’est dans le plugin Maintenance de Contrib.
Je pense aussi qu’on pourra supprimer les checks que je faisais sur le Gitea car si on passe par un autre mécanisme d’inscription il ne doivent plus être nécessaire.

18

Et essayer d’en discuter ça n’aurait pas eu un peu de sens ?

19

J’aimerais surtout qu’on facilite l’accès des personnes qui veulent simplement remonter ou commenter des bugs, mais bon, c’est une proposition. Le fait qu’il y a cette option de valider les conditions d’utilisation ça paraissait plutôt bien.

Je ne pense pas que ça soit une urgence !

20

Etant donné que nous recréons les comptes sur Gitlab, on ne pourrait pas en profiter pour virer les comptes qui n’ont jamais été utilisés sur Gitea ?
Je crois que c’est assez simple de le savoir.