La refonte du site web en multi-langue soulève plusieurs problématiques.
Simple : Modifier le site directement sur github avec une génération automatique par Pelican, puis un déploiement en continue. Entraîne des crash du site.
Laborieux : Faire un fork et tester un build sur sa machine avant de faire une pull-request sur le dépôt du site. Cette méthode n’est pas accessible à tous.
La solution est peut-être dans un nouveau concept de CMS qui semble à la mode, les CMS Headless.
Cela consiste à ajouter une interface d’édition pour les contributeurs de contenus, qui va taper une api pour mettre à jour une base de donnée. Un déploiement automatique est alors lancé avec le générateur de site static qui s’appuie uniquement sur la base de donnée.
Ainsi, le site ne peut pas crasher car les template markdown sont généré proprement depuis la database.
C’est ce que j’ai compris du principe.
Je m’en remet personnellement à vos décisions concernant le site.
Je trouvais très bien d’avoir les sources sous Git pour l’historisation et la réplication rapide de celui-ci grâce à Pelican. Toutefois si vous préférez une autre solution, aucun soucis.
Bah ce qu’on essaye de faire, c’est un git-based headless cms en pelican. Je vois pas vraiment la différence avec ce qu’ils proposent dans le lien que tu as donné.
Nous on veut juste une étape manuelle pour être sûr qu’il n’y a pas de problème. (D’ailleurs j’aimerais bien savoir quel a été le problème). L’édition dans gitlab est à la portée de tout le monde, moyennant cinq lignes de tutoriel, et il suffit d’une personne qui suive les pull request, qui les accepte si elles sont légitimes, et qui met à jour le site quand nécessaire. Ça se fait vraiment en une ligne, c’est honteusement facile.
Mais je te remercie de relancer le sujet : j’ai besoin de savoir quels serveurs on a à disposition et sur quel serveur on sert le site. Je peux même servir le site sur mon serveur personnel si c’est ça qui manque. Il a un uptime de 99%, il faut juste me donner un certificat SSL et faire pointer le domaine sur mon IP (v4 et v6 bien entendu). Et il faut juste qu’on se mette d’accord sur qui fait quelles étapes de la migration. Comme exemple, une version du site multilingue est déjà disponible sur index.trentesaux.fr
Un URL “preview.duniter.org” pour les tests, et une étape de CI particulière manuelle pour lancer la publication. C’est une très bonne idée et je ne vois aucune raison de ne pas la mettre en oeuvre
Suite à l’inquiétude de @elois que je partage, je propose juste d’ajouter, quand on aura un peu de temps, et après ton travail sur le multi-lingue, un frontend wysiwyg pour contributeurs non développeur (uniquement pour la partie blog).
Rien à changer côté pelican.
Bah ce qu’on essaye de faire, c’est un git-based headless cms en pelican. Je vois pas vraiment la différence avec ce qu’ils proposent dans le lien que tu as donné.
Je n’ai pas compris cela, juste que tu regroupais deux sites en un seul multi-lingue… C’est pourquoi je propose ces liens en plus qui font l’état des lieux des cms headless pour des contributeurs non développeur.
Facile à dire, comment savoir si le markdown est bon puisque gitlab ne gère pas le plantuml et a sûrement des différences avec pelican (quid du support du format .rst ?). Il faut donc faire un build manuel chez soi pour vérifier. Une galère.
Non la solution pour faire des modifs directement dans gitlab et voir le résultat dans pelican, c’est la proposition d’@inso qu’il faut adopter : un site de preview. Amha.
Gitlab pages se contente d’installer pelican dans une machine virtuelle (docker) donc ça marche exactement comme pelican. Le résultat est là : https://pages.gitlab.io/pelican
Pour plantuml, il y a peut être moyen de le faire marcher mais ça triple le temps de compilation alors qu’on pourrait compiler les graphiques une seule fois et les utiliser comme images par la suite.
Très bonne idée pour le front-end pour la participation. Ce sera plus simple pour les gens qui ont peur de gitlab. Il faudra aussi à terme le faire pour les traductions mais je m’en occupe.
Ok donc si je fais une page en .rst, elle ne sera pas interprétée proprement par le navigateur de code (markdown gitlab), mais pelican sera lancé et poussera le résultat sur le site de preview. Impec !
Pour plantuml, oui c’est vrai que recalculer des schémas qui sont définitifs est inutile, mais cela m’étonne de la part du plugin. Est-tu sûr que le plugin n’a pas un cache pour ne pas recalculer un schéma non modifié ?
J’ai aussi toujours constaté ce recalcul des images, c’est assez pénible. J’imagine qu’il doit y avoir une option quelque part pour désactiver ce comportement mais je n’ai pas cherché.
Je sais pas pourquoi @vit tu dis que gitlab n’interprète pas le rst. @cgeek tu peux retirer plantulm de pelicanconf.py et le remettre dans publishconf.py comme ça tu compiles les graphes que quand tu veux publier. Sinon, on peut s’organiser pour compiler ça séparément.
Si ce n’est pas le cas, ma proposition :
La CI actuelle produit non pas le site de prod mais un site de test, et on rajoute une étape de publication manuelle qui reprend la version de test et la met en prod.
C’est quelque-chose dont je peux me charger si ça vous semble une bonne solution.
J’avoue que j’ai un peu décroché du sujet. Comme la fusion des sites impliques quelques changement sur les articles et les pages, j’ai peur de devoir tout reprendre à la main le jour où on décide de mettre ça en place pour de vrai. Et malheureusement en ce moment mon temps est complètement bouffé par ma thèse, donc je ne vais pas pouvoir m’y atteler.
Ok, il n’y a pas de .gitlab-ci.yml du coup, le passage du source au site passe par un autre mécanisme du coup, ma proposition ne marche pas en l’état actuel.
Pour autant, ça à l’air de passer par Pelican, or, c’est aussi le cas du site geconomicus, qui passe désormais par gitlab-ci pour son build.
Qui s’est occuper de la métode de build actuel du site de duniter ? @cgeek ? @gerard94 ? @vit ?
du coup, ma proposition ne marche pas en l’état actuel.