i18n: check messages are translated and compile successfully in CI (#71227) #5
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/71227-ci-translations"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
tox -e i18npour lancer le check.A discuter ensemble sur à quel moment on l'applique (sur les PR, sur main, uniquement sur les tags, etc.)Discuté lundi : on teste quelque temps sur chrono sur les PR et on généralise / adapte si ça pose problème.
Build qui tourne sur Jenkins :
Je relance un build avec des trads manquantes / fuzzy exprès
Build avec des traductions manquantes
5e219f330bto3627325e0bPrêt pour la relecture, si quelqu'un se sent :)
Je pense que ce serait plus sympa d'avoir des vrais sauts de ligne plutôt que des \n, non ?
3627325e0btod5f2cd01bdd5f2cd01bdto0b14926d980b14926d98toecb6a87b12Corrigé, ça donne ça maintenant : https://jenkins.entrouvert.org/job/gitea-wip/job/chrono/job/PR-5/7/execution/node/14/log/
(aucune idée de pourquoi les sauts de lines supplémentaires avant les quotes, mais au moins maintenant on a bien un truc par ligne et on peut voir les chaines non traduites ou fuzzy dans le détail)
ecb6a87b12to679c6cce71Après un rebase sur main, on a le check qui plante sur cette chaine qui n'est effectivement pas traduite:
Tous les autres checks passent, je propose de merger et de traduire séparément.
Pour discuter un peu du fonctionnement, je proposerais que ça ne fasse pas échouer les branches wip/, dans l'idée qu'en phase de développement, on a envie de pouvoir pousser une branche tôt, et qu'à ce moment on est concentré sur le code et les tests, qu'être interrompu par jenkins en erreur disant qu'il faut déjà se préoccuper des traductions, ça va casser trop régulièrement la concentration.
Évidemment ça suppose ensuite qu'une fois envoyé dans la branche principale, on envoie également les traductions, et si on oublie, que le job jenkins échoue, on les ajoute tout de suite. J'ai conscience d'un peu me tirer une balle dans le pied en misant uniquement sur ça, mais il y aura bien quelqu'un/e pour voir l'erreur (vs actuellement juste une préoccupation avant de tagguer), et je pense que le gain serait donc déjà là.
c77649acdfto512010265fActivé uniquement sur main, est-ce que c'est bon pour toi @fpeters ?
C'est un sacré pari, ça suppose que le petit choc électrique d'avoir fait planter le build principal instaure vite le réflexe pavlovien de faire ses trads avant de pousser.
Si ça n'arrive pas il faudra revenir en arrière, je ne pense pas qu'on veuille d'un monde où les builds soient régulièrement en erreur (ce qui diminuera aussi l'attention collective qui y est apportée).
D'ailleurs pour avoir plus de chances que le pari soit validé il faudrait ajouter un truc à jenkins pour que la personne qui a fait planter le build principal soit notifiée (actuellement c'est une info qu'il faut souvent pointer via jabber).
Alternativement il me semble que ça existe les hooks git côté serveur pour refuser un push, on ne pourrait pas simplement refuser le push sur main si les trads ne sont pas là ? (makemessages prend trois plombes mais ça vaut peut-être le coup de regarder ce qui prend tant de temps et avoir une commande custom plus rapide)
Quel est l'avantage d'avoir un hook serveur qui refuse les build par rapport à un check en CI ? Le résultat sera le même, on ne pourra pas merger sur main, mais au moins dans Jenkins on a les logs, on peut afficher des choses, etc.
Le hook ce serait un truc qui refuse l'envoi (git push retourne une erreur « fais tes trads et reviens me voir ensuite »). Ça serait mieux à tout point de vue il me semble, avec l'énorme désavantage d'avoir un git push plus long (en l'état actuel la seconde que prend makemessages parait excessive, sans parler de la nécessité du venv qui peut également être un point bloquant).
@vdeniaud je ne comprends pas en quoi c'est mieux que de le faire dans jenkins lors d'une PR. Sur Jenkins lors d'une PR (ou même simplement sur main), on a :
tox -e i18nest extrèmement rapideSur un hook de commit côté serveur :
Plus généralement, dans un workflow à base de pull request où les merges sont effectués via l'interface Gitea (je sais que tu ne fais pas ça@vdeniaud, mais la plupart d'entre nous oui), il n'y plus que rarement de push sur main en CLI.
Le main de gitea est par définition à jour quand on clique sur merge. Un tel hook viendrait donc interrompre le merge de la pull request avec un message d'erreur, au dernier moment. Autant l'avoir dans le build jenkins, pour un résultat identique mais à la fois plus maintenable et plus lisible.
@fpeters je ne comprends pas cet argument. Si tu pousse une branche, les tests vont tourner, ça cassera, mais ça ne t'empèche pas d'avancer sur ton travail, c'est simplement un rappel qu'il y aura des choses à finir avant le merge. Un peu comme quand tu travaille sur une feature et que tu pousse en pensant avoir résolu le bug et que ça casse les tests ailleurs, ça aide à se rendre compte qu'il y a un pépin.
L'idée était d'éviter du travail en downstream à la personne qui va faire une release d'une brique. Évidemment, on est face à un compromis. Est-ce que la concentration/le temps de la personne qui bosse sur sa branche est plus importante que la concentration/le temps de la personne qui fait la release ? Pour moi, la personne qui fait la release est probablement plus stressée et doit gérer plus de choses que la personne qui fait un dev en amont et ça a donc du sens de déplacer une partie de la charge mentale au moment du dev.
La proposition ne semble pas faire consensus, ni sur le moment adéquat pour appliquer la vérification (PR, main), ni sur la façon d'appliquer la vérification (Jenkins/CI, hook git). J'ai passé suffisamment de temps là dessus, j'arrête. Si quelqu'un souhaite reprendre le lead sur ce sujet, le code reste dispo ici :)
Je ne me suis pas positionné là dessus, je réagissais bien à « jenkins que sur main ».
Mon idée c'est vraiment de tout faire pour éviter de casser main, je suis peut-être trop tatillon.
Yep mais comme on va lancer soit même makemessages derrière on aura vite les infos.
Je pense qu'on peut (utile notamment si le hook disfonctionnait).
C'est peut-être techniquement impossible, je l'ai écrit plusieurs fois. Reste que dans une version bête ça reviendrait à installer django sur le serveur git, lancer django-admin makemessages sur le projet avec les options qu'on a normalement dans notre makemessages custom, et voilà (pas de venv et script d'une ligne).
Ça peut être combiné avec jenkins dans l'idée que peut-être la simplicité du hook lui ferait rater des trucs.
Doubt it, alors que rater la notif qu'on vient de péter le build principal ça arrive tout le temps.
En parlant de notif, la solution git hook évite à tout le monde de se prendre une notif/cliquer dessus/voir qu'il s'agit des trads quand quelqu'un oublie de faire ses trads. Faire les choses en amont, dès que possible, semble plus efficace.
Ouch j'avais tout à fait zapper ça, avec un peu de chance gitea affiche un message intelligible (gitlab le fait).
Oui en fait en partie j'en suis venu à me dire que ça ne faisait pas partie des bouts qui pouvaient se corriger par la technique, au mieux ça déplace le problème; si l'attention n'est pas là pour faire la traduction, l'attention sera-t-elle là pour corriger un build en erreur, ou sera-ce toujours pour les mêmes personnes, qui plutôt qu'avoir l'attention portée sur la traduction au moment du tag auront désormais à intervenir pour réparer le build à tout moment ?
Bref, vaiment désolé pour le temps que tu as passé là-dessus :/
Pull request closed