Pour l’erreur 500 je vais essayer de regarder les log serveurs. Cette erreur en l’état ne me dit rien.
Pour la seconde erreur, je pense que c’est la mise à jour du thème. J’ai constaté le problème mais n’étant pas systématique et avec des rechargements navigateurs/serveurs j’avais opté pour un problème de mon coté avec un cache mal actualisé. Si c’est constaté par d’autres je vais regarder plus en détail.
Du coup je serai bien tenté de refaire un clone du dépot spip/spip et remplacer le dépot existant par le clone.
Les issues, PR, … sont maintenues du coup ça ne devrait rien casser à l’existant.
J’ai besoin d’un coupure de service de 40’ environ, le temps que le clone se fasse
@azerttyu s’il te plait, non, on ne touche pas au dépot SPIP, on va perdre des infos historiques
Là quand je compare
et
je vois qu’il manque plein de messages intérmédiaire dans la PR (des messages générés par gitea au fur et à mesure de la vie de la PR comme « @xx a force pushé », « @yy a référencé cette PR », « @zz a fermé cette PR » etc) parce que ce sont des messages générés et pas user et que le clone ne garde pas tout.
Je suis en train de scripter la migration vers gitlab pour récupérer tous ces messsages, et ce serait assez dramatique de saborder le dépot et l’historique des PR et issues avant ça, parce qu’une fois perdu c’est perdu.
@nicod merci pour avoir ouvert les tickets.
Je crains malheureusement que c’était inutile Cela ne semble pas pertinent de consacrer du temps dans une amélioration qui ne servira strictement à rien.
Je mets en attente dans l’immédiat le temps d’avoir une meilleure visibilité sur la suite.
tu as ajouté un clone spip/spip_duplicates qui me complique le suivi des PR parce que Sign In - SPIP on GIT a par conséquent toutes les PR sur spip dupliquées
ce matin je viens d’envoyer 2 commits dans master de spip/spip, sans force…
Et les 2 commits envoyés ne sont plus dans le repository. Il va de soit comme à chaque fois que Shiraz nous a bien notifié des dits commits…
dev git:(master) git push git:(master↑2|⚑12)
Énumération des objets: 21, fait.
Décompte des objets: 100% (21/21), fait.
Compression par delta en utilisant jusqu'à 10 fils d'exécution
Compression des objets: 100% (12/12), fait.
Écriture des objets: 100% (12/12), 1.25 Kio | 1.25 Mio/s, fait.
Total 12 (delta 9), réutilisés 0 (delta 0), réutilisés du pack 0
remote: . Processing 1 references
remote: Processed 1 references in total
To git.spip.net:spip/spip.git
224da03f0..62aed1652 master -> master
[09:11:01] <shiraz> [spip] 2 commits par jluc (Envoyé par marcimat)
[09:11:01] <shiraz> — https://git.spip.net/spip/spip/commit/a934919b : fix: Ne pas relancer par mail la validation de l'inscription des auteurs sans mail Refs: #5863
[09:11:01] <shiraz> — https://git.spip.net/spip/spip/commit/62aed165 : docs(Changelog): pour #5863
[09:11:01] <shiraz> [spip] PR n°5863 : Nouveau commentaire par marcimat | https://git.spip.net/spip/spip/pulls/5863#issuecomment-107804 : C’est intégré.
[09:11:02] <shiraz> [spip] PR n°5863 fermée par marcimat | https://git.spip.net/spip/spip/pulls/5863 : fix: Pas relancer par mail la validation de l'inscription des auteurs sans mail
[09:11:36] <marcimat> NAN mais c’est une BLAGUE ?
[09:11:45] <marcimat> je vais finir par pleurer…
[09:12:01] <shiraz> [spip] PR n°5863 : Nouveau commentaire par JLuc | https://git.spip.net/spip/spip/pulls/5863#issuecomment-107806 : Ah c'est pas la PR qui compte mais les commits unitaires ? pfff Et pourquoi dois je "Actualiser la branche par fusion" (qui ne marche pas / ne change rien)…
[09:14:01] <shiraz> [spip] PR n°5863 : Nouveau commentaire par marcimat | https://git.spip.net/spip/spip/pulls/5863#issuecomment-107807 : JLuc, touche à rien… Y a Gitea qui fait des siennes de nouveau !
Il y a peut-être quelque chose du côté de la synchronisation des dépots clonés; ici j’avais le repository Jluc/spip en remote pour pouvoir cherry-pick ses commits et reprendre ses logs de commits et en fusitonner 2… bref, c’est pour ça que je n’ai pas utilisé directement l’interface de Gitea de la PR.
Je / on regarde l’état des PR de toute l’organisation spip/ (le lien org/spip/pulls) pour avoir un aperçu global ; pas que sur spip/spip/pulls (et oui là c’est bon, je sais bien !)
Ah bah nous n’avions pas vu pour Salvatore également, mais il semble donc que ça fait 2 nuits qu’il commit dans master et que son commit se perd ensuite. Ce qui correspond aux 2 commits indiqués.
Il en fera un 3è demain matin rebasé sur les modifications de master… attendons.
En faisant la différence entre le clone de spip/spip qui a géré une PR sans erreur et le dépot spip/spip j’ai vu des différences de paramétrage au niveau du dépôt à proprement parler.
J’ai ajusté la configuration en retirant ce qui me semblait superflu, à voir.
Cela dit, après je vais sur mon autre site 4.2 pour faire le report… et je pull d’abord… et là je suis étonné de voir une mise à jour forcée… Et effectivement plus tôt j’avais envoyé 2 commits là bas aussi, qui viennent d’être écrasés localement… en revenant en arrière donc.
git pull git:(4.2|⚑2)
remote: Énumération des objets: 23, fait.
remote: Décompte des objets: 100% (23/23), fait.
remote: Compression des objets: 100% (23/23), fait.
remote: Total 23 (delta 4), réutilisés 0 (delta 0), réutilisés du pack 0
Dépaquetage des objets: 100% (23/23), 89.70 Kio | 5.98 Mio/s, fait.
Depuis git.spip.net:spip/spip
+ cce4c7c11...c0d318622 4.2 -> origin/4.2 (mise à jour forcée)
Comme d’hab shiraz avait notifié les commits, et même l’interface de Gitea est au courant :
Si je savais quel truc voudou avait lieu on n’en serait pas encore au diagnostic … et le problème serait réglé.
Vu que la fusion sur master s’est passé correctement, on peut espérer que les dernières modifications sur le dépôt sont sur la bonne voie.
Pour ce dépôt spécifique, il y a longtemps on avait activé l’option bigFileThreshold=1m ce qui est très bas la configuration par défaut est 512m
Cette option n’est pas présente sur le clone réalisé ou sur tout autre dépôt de la forge. Pour rappel on a eu pour diverses raisons eu à faire des configurations très spécifique pour ce projet.
De vague mémoire c’était un problème de charge et un effet de bord sur le cache qui n’arrivait plus à suivre.
Cette option a été retirée avant l’action de fusion précitée. Et je n’ai pas d’autres changements notable autre.
Et Salvatore a bien essayé de commit, mais le commit n’y est pas
[01:31:01] <shiraz> [spip] 1 commit par Salvatore | https://git.spip.net/spip/spip/commit/36ab2f7d : i18n: [Salvatore] [source:ecrire/lang/ ecrire] Export depuis https://trad.spip.net de la langue de i18n: [Salvatore] [source:ecrire/lang/ ecrire] Export depuis…
[01:43:31] <marcimat> ah https://git.spip.net/spip/spip/ bah il y est pas le commit de salvatore
Cela ne semble pas pertinent de consacrer du temps dans une amélioration qui ne servira strictement à rien.
