Ajout du fournisseur Git Forgejo et amélioration de l'expérience utilisateur associée#4194
Open
jtraulle wants to merge 4 commits into
Open
Ajout du fournisseur Git Forgejo et amélioration de l'expérience utilisateur associée#4194jtraulle wants to merge 4 commits into
jtraulle wants to merge 4 commits into
Conversation
Nouvelle hiérarchie d'erreurs "métier" partagées entre providers via mixins ; validation de format et d'accès effectif au dépôt Git dès la saisie dans le formulaire ; vérification réactive lors de la synchronisation et tests associés.
Nouveau client REST générique (Git::Providers::Concerns::RestClient) pour les providers Git sans gem cliente dédiée, avec hiérarchie d'erreurs (HTTPError/NetworkError/InvalidResponseError) utilisé pour la nouvelle implémentation du provider Forgejo et tests associés. Signed-off-by: Jean Traullé <j.traulle@nnx.com>
- Ajout d'un bouton "Tester la connexion" pour vérifier à la demande si la connexion au fournisseur Git configuré est toujours valide. - conditional.js modifié pour masquer les champs non pertinents selon le provider sélectionné (endpoint, autoupdate_theme). - Ajout d'un mécasmisme permettant de cacher dynamiquement un élément en cas de modification d'un champ présent dans une div - Affichage du endpoint par défaut de façon dynamique en tant que placeholder du champ. Signed-off-by: Jean Traullé <j.traulle@nnx.com>
- Permettre le renvoi de l'ensemble des fichiers vers le fourisseur Git (utile en cas de changement de fournisseurs/dépôt) Signed-off-by: Jean Traullé <j.traulle@nnx.com>
Member
|
Wow @jtraulle trop cool merci beaucoup !!! |
Author
|
Oui, avec plaisir :) C'est possible cette après-midi pour moi. |
Member
|
j'ai fait une invit avec ton mail opencomp, ça va ? |
Author
|
parfait, bien reçue :) |
Member
|
Donc plusieurs sujets :
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Type
Il y a des choses complètement nouvelles, la correction d'un bug et de nombreux ajustements.
Description
L'objectif premier de cette PR était à l'origine l'ajout du fournisseur Git Forgejo. J'ai finalement pas mal débordé et j'en ai profité pour apporter quelques améliorations générales à ce qui touche à la synchronisation Git.
J'ai essayé de séparer ça en plusieurs commits afin que ça reste clair et facilement révisable pour vous.
N'hésitez pas à me poser des questions si besoin.
Refonte de l'architecture des providers Git
Certaines choses qui ne l'étaient pas ont été remontées au niveau du
Git::Providers::Abstract. J'ai également ajouté un système d'erreur "métiers" partagées entre les différents fournisseurs avec des mixins afin de pouvoir les attacher aux classes d'erreur des gems pour les fournisseurs Git basés sur une gem.L'objectif étant de pouvoir distinguer/identifier plus facilement les différents types d'erreur en lien avec la configuration Git.
Cela permet ensuite de valider lors de la saisie dans la page Site / Réglages / Technique les informations saisies par l'utilisateur afin de s'assurer que la configuration est correcte.
Ce n'est pas parce que la configuration est valide lors de l'enregistrement qu'elle ne va pas dériver par la suite (expiration du jeton d'accès, dépôt supprimé, branche supprimée ou renommée ou protégée alors qu'elle ne l'était pas avant, etc.)
La validation est donc rejoué lors de l'exécution d'un job de synchronisation d'arrière-plan mais uniquement en cas d'échec rencontré (de cette façon, on ne fait pas d'appel API inutile car le cas le plus fréquent reste une configuration qui demeure valide). Lorsque l'on rappelle la validation dans ce cas, un email est également envoyé pour notifier les administrateur du défaut avec la synchronisation Git sur le site en question avec le détail.
Note : j'ai ajouté les administrateurs de serveur dans les utilisateurs cibles des notifications envoyées car ce n'était pas le cas actuellement (sans doute un oubli).
L'intérêt de distinguer le type d'erreurs Git, c'est aussi de pouvoir avoir un traitement différent au niveau des jobs d'arrière-plan GoodJob : retenter un certain nombre de fois les erreurs transitoires (erreurs réseau, serveur) et abandonner directement les erreurs qui n'ont aucune chance de se résorber seules sans intervention de l'utilisateur pour la mise à jour des paramètres Git.
J'ai aussi corrigé un bug au niveau du stockage de la date de dernière synchronisation : actuellement, la date était modifiée dès le lancement de la tâche du synchronisation donc, en cas d'échec en cours de route (token expiré, etc.), il n'était pas possible de renvoyer les pages modifiées sans effectuer une nouvelle modification dessus sur osuny. Maintenant la date n'est redéfinie qu'à la fin ; un test a aussi été ajouté pour ne pas afficher le bouton "Synchroniser" si une synchronisation a déjà été demandée et est en attente ou en cours de traitement.
Enfin, une méthode pour permettre d'invalider/marquer désynchronisé l'ensemble des fichiers pour forcer leur renvoi. C'est utile par exemple si le dépôt vers lequel on synchronise change ou même le fournisseur complètement. Actuellement j'ai fait se déclencher ce mécanisme automatiquement si le champ provider ou repository est modifié. MAIS, en y réfléchissant ce n'est peut-être pas une bonne idée (le nouveau dépôt en cas de changement à pu être préparé en amont pour être identique à celui utilisé auparavant). Peut-être donc laisser uniquement l'exécution de ce traitement de façon manuelle et à l'appréciation d'un administrateur de serveur (à recouper avec le détail du 4e commit).
Ajout du fournisseur Forgejo
J'ai regardé s'il y avait une gem et il y en a bien une mais elle est auto-générée à partir de OpenAPI Generator et elle pèse donc plus de 25 Mo. J'ai donc fait le choix de plutôt partir sur un classe outil légère pour faire un petit client HTTP pour faire des requêtes vers une API REST (
Git::Providers::Concerns::RestClient) et les classes d'erreurs associées.Il pourra éventuellement être réutilisé pour intégrer d'autres fournisseurs Git.
Améliorations fonctionnelles page Site / Réglages / Technique
Enregistrement.d.ecran_20260714_230618.webm
Ajout d'un bouton permettant de vérifier les paramètres de connexion au fournisseur Git.
Cacher le champ "Point d'accès Git" si l'utilisateur choisi le fournisseur Git GitHub.
Cacher la case à cocher de mise à jour auto du thème pour le fournisseur Git Forgejo (pas possible de mettre à jour la référence d'un sous module avec l'API Forgejo).
Afficher dynamiquement les valeurs par défaut en fonction du fournisseur Git sélectionné dans les champs Point d'accès Git et Branche en tant que placeholder (donc si rien n'a encore été saisi dans le champ).
Cacher le bouton de vérification si l'un des champs de paramètres Git est modifié de façon à forcer l'utilisateur à déclencher la validation avec le bouton Enregistrer.
Ajout d'un bouton admin "Forcer le renvoi de tous les fichiers"
Le but est ici de forcer le renvoi de l'ensemble des fichiers vers le fournisseur Git (en lien avec le dernier paragraphe du détail concernant le premier commit. Il faut tout de même relancer la synchronisation manuellement avec le bouton.
Tests
J'ai ajouté des tests pour Forgejo sur la base de ceux déjà là pour GitHub et Gitlab ainsi que d'autres tests selon les problématiques rencontrées. S'il en faut d'autres, n'hésitez pas à me l'indiquer.
Contribution connexe prévue
Je pense également proposer une PR de mise à jour de la documentation disponible ici pour détailler la procédure de création d'un jeton d'accès pour les 3 fournisseurs différents et les permissions requises.
Niveau d'incidence
Je ne sais pas trop comment vous qualifiez le niveau d'incidence donc j'ai mis moyen.