Migration de la zone vers un Gitlab

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 »

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 => []

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 »

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 »

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.

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.

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 ?

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

Mais dans le cas d’une connexion avec Github ?

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

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 ?

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.

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

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 !

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.

Il y a beaucoup de traitements via l’API Gitlab au moment de l’import, et du coup oui ça prend la date de mise à jour à cet instant dans Gitlab, ce qui classe les projets… à peu près dans l’ordre alphabétique de traitement… Je ne crois pas qu’on ait de solution à cela lors de l’import.

Un compte inutilisé n’a pas d’effet sur la forge actuelle.

Dans gitea, c’est assez simple à identifier car ce sont des des comptes qui n’ont a été connecté depuis leur création.
Ensuite la gestion actuelle c’est de traiter les boucnces (retour d’erreur email) à la main.
Si un compte mail retourne des erreurs, je vérifie si le compte a été utilisé ou non depuis sa création. Sinon il est désactivé, si oui je contacte la personne en direct. La majeure partie du temps c’est le premier cas.

Oui mais ça permet de faire un peu de ménage sur les comptes surtout que les mots de passe vont changer.
Je pense qu’il vaut mieux garder uniquement des comptes actifs, enfin à mon avis.

Ben ça dépend de quand on souhaite migrer. On a une date ?

Si. tu vas dans le dashboard de Contrib tu vois qu’il n’y a pas des inscriptions tous les jours.
Et si on peut tout faire par Gitlab sans perdre la capacité de filtrer les comptes fake ça le fait aussi et ça évite de maintenir une autre alternative avec du code. Le dashboard de Contrib montre qu’il y a une inscription sur deux qui est une fausse inscription.

Ah oui, c’est juste, il y a la recherche de code sur chaque projet par défaut déjà tout de même.
On regardera pour activer la recherche avancée qui permettrait de chercher du code sur l’ensemble de la forge.

Bah non, quand tu cherche une fonctionnalité tu n’as pas forcément en tête le nom du plugin associé.
C’est même une des raisons de la page actuelle de la forge qui propose une recherche globale par défaut.

Donc vous avez souscrit à l’offre payante ? Vu que cette fonctionnalité n’est pas, à ma connaissance, native à la version communautaire.