Depuis une semaine nous avons tous les jours la notification de ce commit (et d’un autre) [Salvatore] [source:ecrire/lang/ spip] Export depuis https://trad.spip.net de la langue en · 37d1a6c82d - spip - SPIP on GIT
Au moins là on est notifié 
Tiens… qu’est-ce qu’il se passe encore ’
- [Salvatore] [source:ecrire/lang/ spip] Export depuis https://trad.spip.net de la langue en · 37d1a6c82d - spip - SPIP on GIT
- le commit parent est fix: Notice sur _chemin(null) · c05affcd44 - spip - SPIP on GIT qui est le HEAD du master actuel
- le master n’est pas déplacé sur le commit de salvatore (c’est ça le bug j’ai bien l’impression)
- et donc Salvatore n’est jamais au courant que la modification est prise en compte
Bien je ne sais pas… la seule chose qu’on ait faite, c’est mettre à jour le site trad.spip et ses plugins dans la nouvelle version de SPIP, mais je ne vois pas de rapport évident.
Je peux même dire que du point de vue de nos scripts, le commit est bien passé
2024-01-03 01:30:01: [master 37d1a6c82] [Salvatore] [source:ecrire/lang/ spip] Export depuis https://trad.spip.net de la langue en
[...]
2024-01-03 01:30:05: To https://git.spip.net/spip/spip.git
2024-01-03 01:30:05: c05affcd4..37d1a6c82 master -> master
2024-01-03 01:30:05: Module spip OK
Donc ça veut dire que les commits de salvatore ne sont plus dans master ? Et ça semble être le cas depuis 4 mois cf https://git.spip.net/spip/spip/commits/branch/master/ecrire/lang
Bonjour
Je regarde ce qu’il en est coté gitea.
J’ai stoppé certains hooks l’autre jour suite aux remontées des lenteurs constatées lors des git push.
C’était dû au miroir github en mise à jour synchrone. Et par effet de bord j’ai retiré tous les hooks non identifiés.
Peut être que salvatore en fait partie, il a un accès spécifique pour faire ses commits.
Et que vois-tu donc ? Parce que… ce n’est pas le seul problème sur spip/spip
- Ce matin la PR build: ecrire/boostrap/config doit être présent dans le zip généré par Composer (!5817) · Requêtes de fusion · spip / spip · GitLab ajoutait un commit juste après
master, et pourtant l’encart indiquait que la PR n’était plus à jour ; - Puis ce matin, j’ai voulu merger fix: HTML valide pour le formulaire `configurer_redacteurs` (!5819) · Requêtes de fusion · spip / spip · GitLab qui a tout fait comme si c’était mergé (rebasé) dans master… mais… les commits n’y sont pas arrivés (mais on a bien eu toutes les notifs par contre). Exactement comme ce qu’il se passe avec Salvatore.
Bonjour
Pour le bégaiement en terme de mail, je ne trouve qu’une notification partant vers la liste. J’essaye de voir plus en détail mais sur ce point dans l’immédiat j’ai l’impression que c’est hors de mon périmètre.
J’ai modifié le comportement du cache coté gitea, qui peut dans certains cas être non synchrone entre les commits réels et leur affichage
L’affichage semble cohérent avec ce que je vois sur le depot git. J’ai bien comme dernier commit 183b9d9743cfb356fbc10c06482f73acf4c03ccd pour ecrire/lang
Il y a un temps le script faisait un git push --force c’était la cause de la perte de certains commits.
1/ J’ai en théorie bloqué les force sur les branches main et master, mais je n’ai pu tester si les comptes administrateur outrepassent cette règle.
2/ Je viens de basculer ce profil dans un groupe « bot » avec des droits généraux d’écriture. Cela devrait réduire leur autorisation de base.
Je regarde dans les historiques si je peux avoir plus de de détail sur les actions réalisées sur le dépôt par les bots.
Bonjour
Je constate un truc étrange, j’ai l’impression que salvatore dépend du compte marcimat
Le commit Salvatore est bien présent :
Mais de ce que je vois il est lié à la branche pull/5812/head
Ce qui est cohérent avec ce qui est indiqué plus haut par @marcimat
Mais cela ne semble pas cohérent avec la PR 5812 qui semble pointer sur autre chose
Tu vois cela où ? le parent est toujours le dernier commit de master pourtant sur https://git.spip.net/spip/spip/commit/37d1a6c82da30f9668b2715194e5436edc043904
Hello
Il y a eu une actualisation … Dans la cascade de dépendance a changé. On vois que le parent est maintenant basé sur master et non plus pull/5812/head
Pour moi il y a bien des push --force dans l’historique :
Si je prends le reflog du serveur :
c2652d58d9 (HEAD -> master) HEAD@{0}: update by push
c2652d58d9 (HEAD -> master) HEAD@{0}: update by push
c2652d58d9 (HEAD -> master) HEAD@{1}: update by push
[...]
c2652d58d9 (HEAD -> master) HEAD@{52}: update by push
a584be8e85 HEAD@{53}: push
1c8dbcaf8e HEAD@{54}: push
c2652d58d9 (HEAD -> master) HEAD@{55}: update by push
[...]
Je modifie la configuration pour bloquer le push --force depuis les hooks. Cela devrait bloquer peut importe le statut du profil utilisateur.Ce n’est pas salvatore qui envoie des push --force alors c’est qui ?
Perso je ne l’avais jamais vu sur pull/5812/head quelque soit le moment où j’avais regardé
Bon dans tous les cas j’ai déployé un hook sur update qui interdit tous les non fast forward (dont les --force)
Si ça essaye d’envoyer du force ça devrait être bloqué
Je me base sur How to use the update hook
Sur toutes les branches ??
Hello
Pour le suivi, vu qu’une partie a été discutée sur IRC.
Le script a été adapté pour essayer de prendre en compte le --force[-with-lease]
Du point de vu du serveur, on ne sait pas qu’on force les commits. On précise juste au serveur qu’on veut pousser un commit dont le parent diverge de celui de référence. (dit autrement no fast forward).
Dans le cas d’un force-with-lease, on peut faire une grossière approximation en considérant que l’auteur est le même entre les 2 commits.
Mais je crains que ça revalide la cas initial où on essaye de protéger de certains push force non identifié.
Il faudrait probablement affiner en ciblant spécifiquement les branches de type PR (non main/master), à affiner selon les retours.
On a aussi constaté qu’un script salvatore a été modifié courant décembre, à voir si cela peut avoir un impact ou non.
- tu ajoutes des hook en affirmant que Salvatore ferait des
--force, ce qui n’est pas le cas. Alors d’où viennent ils s’il y a effectivement des--forcequi passent ? Est-ce une action de Gitea ? - aussi, des PR de spip/spip sont en erreur «Cette demande de fusion est impossible par manque d’informations de bifurcation. » suite à leur rebase. Est-ce qu’on peut savoir ce qu’il se passe ? (je t’assure que ça ne vient pas de la façon dont on fait les commits… push, force, peut importe, y a pas de raison…)
- on a tenté des merges de PR (depuis Gitea) qui ont été déclaré fusionnées dans master (en voyant passer les notifs), qui n’y apparaissent finalement pas… Ça n’a pas à voir avec Salvatore là du coup… Est-ce qu’on a une idée de ce qu’il se passe là aussi ?
Ça fait beaucoup de soucis je trouve 
Les fichiers de crons qui ont été déplacés ; les scripts derrière n’ont pas bougé, et ils sont toujours sur spip-cli · master · spip-contrib-extensions / trad-lang · GitLab
Hello
Non je n’affirme rien concernant Salvatore, je n’ai aucune idée de comment il fonctionne.
Ma seule affirmation est un git push --force-[with-lease] a lieu, ni plus ni moins. C’est ce qu’indique le reflog précédent.
Coté serveur on ne peut connaitre la nature du force, c’est uniquenet un no fast forward qui est envoyé.
La dernière fois qu’on a eu ce problème, c’était l’IDE d’un des contributeurs qui avait la fonctionnalité --force d’active par défaut.
Gitea de son coté ne force rien il réceptionne les commits et les affiche. Sur ce cas de figure en l’état je vois qui incrimine directement un comportement de la forge.
Je rappelle que la configuration de la forge voulue par la communauté, c’est un mode open bar de type administrateur.
Par conséquent tous les profils team peuvent faire ce qu’il veulent sur les dépots. Gitea acceptera sans broncher. N’importe quel compte de l’organisation peut être à l’origine du problème.
Concernant les 2 points concernant les PR, c’est à mon avis l’effet de bord du premier point. Vu qu’un force a lieu les commits des PR et autres deviennent orphelins.
De ce que je vois en regardant les différents point abordé, je retombe souvent sur le commit orphelin build: ecrire/boostrap/config doit être présent dans le zip généré par Composer (c2652d58) · Validations · spip / spip · GitLab qui devrait être sur master de ce que j’ai suivi.
Les PR/commits suivants s’appuyant dessus, sont de même orphelins.
En l’état ce que j’ai fait/proposé c’est de mettre une rustine de type hook, pour réduire les effet d’un push force. Ce hook restreint fortement les push peu importe la provenance des contributions.
La seule exception à cette interdiction est le fait que le commit source serveur et local soit du même auteur. Ce qui permet d’accepter le cas classique du force-with-lease. (Mais avec plein d’effet de bord comme expliqué plus tôt)
Grâce au reflog je peux « restaurer » les commits orphelins et via la base de donnée indiquer les informations de commits actualisées.
Il vient de la PR suivante, mergée avec Gitea : build: ecrire/boostrap/config doit être présent dans le zip généré par Composer (!5817) · Requêtes de fusion · spip / spip · GitLab
En quoi il serait orphelin ?
Oui, et pour moi c’est un problème effectivement que ce soit open-bar… D’ailleurs on en avait discuté en juillet pour revoir ça (réduire la liste des personnes pouvant commiter dessus)… mais bon…
En tout cas, est-ce que là on peut merger des PR de nouveau ? on a le feu vert ?
En plus il faut qu’on rattrape celles qui se sont mal passé…
J’essayais de cherry-pick pour refaire une branche de la PR fix: HTML valide pour le formulaire `configurer_redacteurs` (!5819) · Requêtes de fusion · spip / spip · GitLab
Et en fait, impossible de récupérer les commits en local !
Que ce soit git fetch ou checkout…
git pull
git show 5ace3dd0c96d896924240c0275da7725244e8aca
> fatal : bad object 5ace3dd0c96d896924240c0275da7725244e8aca
# OK je n’ai pas cette référence en local… je la récupère
git fetch origin 5ace3dd0c96d896924240c0275da7725244e8aca
> erreur : Le serveur n'autorise pas de requête pour l'objet 5ace3dd0c96d896924240c0275da7725244e8aca non annoncé
Le commit est là fix: HTML valide pour le formulaire `configurer_redacteurs` (5ace3dd0) · Validations · spip / spip · GitLab et on le voit aussi dans le graph Connexion · GitLab
Je ne vois pas ce que je fais mal !
Hello
Là je ne matrise plus assez les arcanes de git, mais comme ils sont orphelins coté serveur, je ne pense pas qu’ils soient disponibles à distance.
Je dois pouvoir le faire en direct sur le dépot soit en faisant un clone serveur pour avoir les objets.
Peux tu me confirmer que :
- pour salvatore on peut repousser tous les commits depuis le bot ?
- sinon je dois pouvoir les rejouer depuis les reflog , aurais tu les commits/horaire associés ?
- pour les PR nous avons à rattraper :
- Les PR sont bien en rebase sur master ? donc sans de commit de merge ?
Est ce qu’il y en a d’autres PR ?
Mais Salvatore, il n’y a rien à rejouer, les commits sont arrivés dans master hier midi. C’est bon.
Pour les PR.
- Non #5817 est aussi dans master.
- Là il y a #5819 à reprendre oui, mais je peux le faire en exportant les .patch depuis Gitea aussi. Je vais le faire comme cela.
Et pour info sur d’autres lieux j’ai déjà récupéré des commits orphelins via la procédure du dessus, je ne sais pas pourquoi ça bloque ici.