Re: Gitea et le débardeur

Hello,

Oui, le debardeur récupère déjà les zips de gitea, c’est là que ça se passe
https://git.spip.net/spip-contrib-extensions/debardeur/src/branch/master/debardeur/connecteur/gitea.php#L63

Par contre pour github on est obligé de les reconstruire parce que l’API de github est limitée en nombre de requêtes sauf à sortir la grosse artillerie en faisant une auth oauth etc, mais j’ai laché l’affaire. Du coup on clone en git et on zip nous même mais c’est à la marge.

--
Cédric
Le 5 janv. 2021 à 18:52 +0100, Eric Lupinacci <[email protected]>, a écrit :
> Yop,
>
> > Le mar. 5 janv. 2021 à 17:57, RastaPopoulos <[email protected]> a écrit :
> > > Le 05/01/2021 à 17:13, Eric Lupinacci a écrit :
> > > > 1) Le problème ne concerne pas les tags ni la génération systématique des zips par le débardeur. On pourrait même étendre à l'ensemble des tags si on voulait... Maintenant, ne pourrait-on pas éviter de regénérer les zips existant sur Gitea ?
> > >
> > > C'est pas déjà le cas, genre si le débardeur voit que ça existe sur gitea, il le récupère tel quel ?
> > >
> >
> > Ben tu me mets le doute en fait.
> > Cédric ou Matthieu doivent savoir confirmer ou infirmer.
> >
> >
> > >
> > > - https://core.spip.net/issues/3017 dont la conséquence est que SVP devrait être amélioré pour connaitre plus qu'une unique mise à jour existante : en effet à un instant T, un plugin peut avoir une version majeure sortie X+N *et* une version Y+N ou même juste Z+N, et l'utilisateur ne veut PAS forcément changer de X, mais bien changer que Y voire même ne changer que Z pour être sûr de ne rien casser et avoir juste les corrections. Au niveau ergonomique, le travail est en gros fini, mais par contre, la conception de SVP ne le permet pas, donc pas possible de générer plusieurs boutons de mises à jour différentes à la fois. (Exemple de Sézi dans la maquette, qui a 4 mises à jour possible à la fois)
> > >
> > > Ce dernier point est le plus compliqué il me semble, car SVP c'est compliqué et qu'il y a eu un gros angle mort de conception sur ce point on dirait. Cependant j'ai l'impression que pour les utilisateurs finaux (qui ne suivent pas le code), c'est encore bien plus important qu'avoir le changelog complet : les gens devraient absolument pouvoir faire des mises à jour mineures, sans qu'on leur montre uniquement la majeure, et illes sont capables de choisir l'option la moins dangereuse pour elleux même sans changelog complet avec les phrases claires et simples (on comprend la différence entre "màj corrective/fonctionnelle/majeure" et donc la dangerosité ou pas à changer sans tout péter).
> >
> > Je ne suis pas sur que ce soit si compliqué en fait sauf peut-être pour la logique de dépendances.
> > On a commencé une réflexion avec Matthieu (qui a aussi débuté le codage) pour continuer le découpage de SVP en un plugin chargé de construire le référentiel (unique sur un serveur donné) et le plugin SVP d'installation présent sur chaque site qui lit les informations en provenance du premier (avec l'idée du passage à composer in fine).
> > Je pense qu'on peut réfléchir à introduire une logique plus large sur le choix des versions mais il faut spécifier exactement ce que l'on veut réaliser.
> >
> >
> > >
> > > Mais faisons déjà les choses "simples", sur lesquelles on a la main plus vite.
> > >
> >
> > Ok, on s'y prend comment pour lancer ce chantier ?
> >
> > ++
> > Eric
> >
> _______________________________________________
> liste: https://listes.rezo.net/mailman/listinfo/spip-dev
> doc: https://www.spip.net/
> dev: https://core.spip.net/
> irc://irc.freenode.net/spip