c’est sur que cela serait utile, mais pas indispensable non plus, a priori. Cela étant si on part sur les dates de @cerdic pour le moment de la migration, il n’y pas de raison que cela pose problème car cela ne se combinerait pas avec les dates des formations
@JamesRezo on est d’accord que ni le terme gitea_mirror ni le principe lui meme n’est idéal. Mais faute de mieux pour l’instant. Cela étant l’usage pour moi c’est en gros moins d’1/fois ans.
parmis les points importants à cours terme : quid du debardeur?
on va le reconnecter sur le gitlab post migration. Le débardeur est déjà prévu pour utiliser des api différentes, il suffit qu’on ajoute un connecteur gitlab ici debardeur/connecteur at master - debardeur - SPIP on GIT pour implémenter les 2 ou 3 fonctions nécessaires et ça devrait rouler…
Hello,
Une bonne nouvelle pour le dépôt composer de SPIP !
Je viens de (re)tester et valider le combo satis/gitlab et il sera donc possible de référencer les zip générés par la plate-forme Gitlab dans notre dépôt composer. Il ne sera alors plus nécessaire de générer les zips comme nous le faisions avec Gitea.
Cela signifie que la montée en charge du dépôt composer est envisageable bien plus sereinement que jusqu’alors.
Après la migration de ce week-end, je mettrai en place la config coté satis et gitlab pour les packages qui sont déjà référencés. Et on verra plus tard pour la suite…
Ah, dans le genre rattrapage aux branches, je vois qu’on a des URLs de la forme https://core.spip.net/attachments/download/717/Capture%20d_écran%202015-05-03%20à%2023.14.12.png
dans des issues ou commentaires, comme ici #2915 - dans privé en colonne gauche dans h3, chevauchement texte sur lien "plus d'info" - spip - SPIP on GIT
C’est l’ancien dossier des pièces jointes/copies d’écran du redmine je pense. @azerttyu on l’a encore quelque part ? ou @cy_altern ? Si on l’a encore je veux bien récupérer un zip de ce dossier attachments/download pour qu’on puisse continuer à voir les anciennes copies d’écran…
… Bah oui
Se reporter entre autre à Futur svn.spip.net / zone.spip.net / core.spip.net - #2 par azerttyu
L’archive est disponible, je l’envoie à qui / où / comment ?
Pour information, ayant isolé la forge spip des autres instances gitea hébergées, je n’assure plus de maintenance spécifique à son propos.
Ah super, si tu peux la mettre sur vailopaa, tu me dis dans quel dossier et je la récupère, ça sera top, merci !
Je l’archiverai complète sur le serveur avec la forge, au cas où on en aura besoin plus tard, mais donc surtout on pourra rebrancher les images et autres copies d’écran.
C’est dans ton répertoire personnel du serveur
Alors aujourd’hui plus de zip veut dire plus de Plugins SPIP.
Il va donc falloir comme on l’a dit déjà n fois s’y préparer si on veut conserver nos sites Plugins SPIP et Contrib. Mais peut-être que j’ai mal compris le sujet.
Ça ne concerne pour l’instant que les plugins-dist et l’installation par composer pour le développement en local et la fabrication du zip de SPIP5. Quand je faisais référence à Gitea, c’est parce qu’on devait générer des zip dans le dépôt composer. Ça ne change rien d’autre.
Bonjour,
La zone a été migrée sur un Gitlab, et est de nouveau opérationnelle.
En espérant que tout soit en ordre !
N’hésitez pas à signaler des éventuels soucis, là ou avec un ticket sur ce projet
Bon week-end 
Bonjour
Parfait je supprime l’instance gitea en début de semaine.
Yop et pourquoi on n’a jamais essayé : Composer Package Registry | Gitea Documentation ? cela semble bien couvrir le besoin exprimé. Qu’est ce qui t’a fait éliminer cette solution ?
Soyons clair c’est juste pour ma culture générale. Pour le reste le match est plié et cela ne m’intéresse plus.
Qui est ce « on » ?
J’ai réalisé de multiples tests avec plus d’une dizaine de scenarii et c’était très insatisfaisant, loin du compte…
J’en ai longuement discuté avec quelques personnes de la communauté, trop peu nombreuses à mon goût, qui avaient manifesté de l’intérêt pour ce sujet, mais je n’ai pas vraiment envie de recommencer, ça a été épuisant.
…
Je présume toi , moi en tout cas je n’ai pas été sollicité sur ce point.
Merci pour avoir répondu à ma question.
C’est fait ! 
bravo !
Je poste ici car ça n’est pas un problème avec la migration de contenu. Les notifications envoyées par gitlab sont postées par noreply@spip.net, ce qui rend difficile leur filtrage dans les boites mails (on a déjà cette adresse d’expédition sur d’autres sites de la galaxie). La solution que je vois, serait de filter sur le champs reply-to: Git SPIP - noreply <noreply@git.spip.net> qui permet bien de cibler les mails envoyés par la forge. Vous avez d’autres idées sur le sujet ?
