La 2eme solution me semble bien. La 3eme pourquoi pas, mais il faudrait que ça soit réintégrer au plugin d’origine pour qu’on ait pas à le maintenir ensuite 
Oui, c’est celle à adopter pour l’instant. La 3 fonctionne si pélican-page-hierarchy accepte les modifications pour le multilingue.
(En attendant, c’était plus facile de faire la 1 automatiquement)
Le problème, c’est qu’en cas de conflit, même si on a la bonne URL, le breadcrumb ne fonctionne plus. Faut voir si c’est acceptable en production ou si on attend de résoudre ça.
Quand est-ce qu’on peut merge ça à votre avis ? Je fais une pull request tout de suite et on met en production ou il manque quelques trucs ? (genre la mise en prod automatique)
Ta PR est un peu grosse.
Faut qu’on y jette un œil attentif.
Et dans, dans le futur, faut qu’on utilise GitLab Pages pour générer le site.
1 Like
Je vais regarder comment marche GitLab pages. J’ai forké l’exemple pour pelican (https://hugo-trentesaux.gitlab.io/pelican/), mais je ne sais pas encore comment installer plantuml par exemple (il faudrait accéder au docker). Et oui, je veux bien qu’on jette un coup d’œil ensemble avant de mettre ça en production.
Plus qu’y jetter “un œil attentif” il faudrait surtout déployer un site de test sur genre test-site.duniter.org afin de ne plus prendre de risque.
On s’est déjà tapé la honte sur linuxfr… Le site duniter est beaucoup consulté tout les jours a toutes les heures de la journée, c’est une folie de continuer à déployer directement dessus comme on l’a toujours fait, il est temps de mettre en place un site de test !
2 Likes
Je comprends pas bien l’erreur du job GitLab pages
console du job (pas de problème à l'installation des dépendances)
Running with gitlab-runner 10.8.0-rc3 (5470b911)
on docker-auto-scale e11ae361
Using Docker executor with image python:2.7-alpine ...
Pulling docker image python:2.7-alpine ...
Using docker image sha256:5fdd069daf25f69ca2cea5dbf4461e9663f8dd6caaab5bd96439b0b16e8958a0 for python:2.7-alpine ...
Running on runner-e11ae361-project-6426436-concurrent-0 via runner-e11ae361-srm-1526729755-43426500...
Cloning repository...
Cloning into '/builds/Hugo-Trentesaux/pelican'...
Checking out 1d7c3f5d as master...
Skipping Git submodules setup
$ pip install -r requirements.txt
Collecting pelican (from -r requirements.txt (line 1))
Downloading https://files.pythonhosted.org/packages/82/62/6a81e2f2c8f20a80643d78ed93de42813c4decc0e3fc341e76106e0f881b/pelican-3.7.1-py2.py3-none-any.whl (134kB)
Et juste un petit warning à la fin :
warning
$ pelican -s publishconf.py
Done: Processed 23 articles, 19 drafts, 24 pages and 35 hidden pages in 6.00 seconds.
Done: Processed 37 articles, 5 drafts, 52 pages and 7 hidden pages in 13.40 seconds.
Done: Processed 37 articles, 5 drafts, 52 pages and 7 hidden pages in 20.50 seconds.
Uploading artifacts...
WARNING: public/: no matching files
Uploading artifacts to coordinator... ok id=69274126 responseStatus=201 Created token=JNELaE3x
Job succeeded
La “compilation” passe, mais le déploiement pas…
[edit] c’était un peu laborieux et je suis vraiment débile, mais voilà le site compilé et servi par GitLab pages https://hugo-trentesaux.gitlab.io/pelican/ (toujours sans platuml)[/edit]
Je plussoie le test avant de déployer sur le site officiel.
J’aimerais bien prendre les choses en main. Pour cela, j’ai besoin de votre avis @cgeek @elois @Moul @Inso sur les points suivants :
- Est-il pertinent d’avoir un site multilingue (chaque langue pouvant toujours se développer indépendamment
- Est-ce que la façon dont je l’ai fait (avec le plugin i18n) est maintenable
- Quel échéancier peut-on se fixer
Deuxièmement, nous souhaitons à tout prix éviter les erreurs comme la “honte” citée plus haut. Pour ça, on propose un déploiement automatique avec GitLab pages sur un site de test, et un déploiement manuel régulier vers le site officiel.
Il faut donc faire les choses suivantes :
- corriger le bug page-hierarchy/i18n
- documenter les conventions d’édition du site mieux que ce que j’ai fait
- ajouter un nom de domaine “test.duniter.org” par ex et le lier aux GitLab pages
- résoudre le problème de plantuml (peut être compiler les graphiques à part, ça ne me paraît pas absurde)
- s’organiser pour le déploiement manuel vers le site officiel duniter.org
Je n’ai pas beaucoup de temps, mais je veux bien le consacrer à ça si je sais que c’est utile. Je ne vais pas m’acharner à faire un site multilingue si vous n’avez pas envie de vous en servir. Mais je pense que ce serait vraiment bénéfique à duniter de profiter de la communauté esperanto, et le meilleur moyen que je trouve d’y arriver est de traduire le site en esperanto.
Je pense que ça fait beaucoup d’un coup de rendre le site multilingue et de gérer son déploiement avec GitLab Pages.
Il faut faire les deux séparément et de manière méthodique.
De plus, notre objectif premier est de libérer un serveur mourant sur lequel se trouvent le site, le serveur XMPP et Weblate et de les migrer sur notre autre serveur.
Donc, dans un premier temps, je mettrais en priorité la migration du site web, avec le déploiement GitLab Pages, puis la gestion du multilingue (à savoir l’ajout de l’espéranto) qui est bien moins prioritaire, bien que je sois très en faveur pour cette langue.
Pour la migration, il faut prendre en considération que le serveur XMPP et le site doivent être migrés en même temps, car ils dépendent du même enregistrement DNS.
Pour la migration du site, on peut voir deux possibilités, migrer le fonctionnement actuel sur notre autre serveur ou implémenter le déploiement GitLab Pages.
Actuellement, il y a disons que moi qui s’occupe du site. Donc, que moi qui pourrais reviewer ton travail, bien que j’ai aussi d’autres priorités en vue.
Voilà, pour l’état des lieux actuel.
J’ai une question concernant la gestion du multilingue de Pelican.
Actuellement, des redirections en fonction de la langue du navigateur est gérée au niveau d’un vhost ngnix.
Pelican, gère ça nativement avec i18n ? et tout le code serait dans le même dépôt git ?
J’ai survolé tes modifications, mais c’est être sûr de ce dont on parle.
1 Like
Oui je suis d’accord, idéalement il faudrais deux job de déploiement, un sur le site de test en automatique puis un sur le site de prod en manuel. Gitlab-ci permet de gérer finement ça donc normalement c’est possible, j’ai juste un doute sur la possibilité d’avoir deux job pages différents, @1000i100 tu en pense quoi ?
Installation de plantuml pour le plugin pelican :
1 Like
J’en pense qu’un rsync pour faire le déploiement, (ou un git pull en ssh) ça marche bien aussi, du coup, rien ne nous empèche d’avoir un job pages en auto, et un déploiement custom déclenchable en 1 clic.
1 Like
Je ne vois pas en quoi c’est difficile. C’est un site statique donc il suffit de copier le HTML. Enfin, pour le XMPP, je ne connais pas… Et si on part sur un gitlab page en deux temps, on peut garder la maj en rsync manuellement pendant un moment, c’est vraiment pas difficile ni chronophage. Pour les redirections, on peut garder exactement la même chose. Pelican génère un sous-site par langue.
Cool si c’est simple pour toi alors le mieux c’est que tu aide directement Moul dans cette tache, nous sommes hélas trop peu nombreux et trop peu disponibles 
C’est exactement mon but ! Je vois bien que vous n’avez plus beaucoup de temps à consacrer au site web, et c’est pour ça que je propose mon aide. Je ne suis pas du tout informaticien, mais je m’entraîne pas mal à l’admin sys sur mon serveur. Je n’ai pas d’expérience avec nginx (seulement apache) ni le protocole XMPP, mais j’ai un blog en pélican, et j’utilise git assez souvent, donc je pense que je peux prendre des responsabilités sur le site web. J’ai évidemment besoin d’une petite relecture pour être sûr de ne pas faire de bêtises, mais je pense que je peux faire du boulot propre.
3 Likes
as tu déjà joué avec les scripts de gitlab-CI ?
1 Like
Non, jamais joué avec ça. J’ai juste essayé le générateur de pages il y a deux jours, mais rien de plus
et bien ça va être l’occasion 
Peux-tu m’en dire un peu plus ?
Bon, c’est pas tout mais j’aimerais savoir
- Si vous êtes favorables
- Dans quels délais est-ce qu’on met ça en place
- Comment on gère les droits : est-ce que je fais une pull request et vous l’acceptez, ou est-ce que j’acquiers les droits sur le git du site web, à quels serveurs je dois avoir accès…
Sinon je risque de me démotiver et de ne plus avoir envie de m’occuper de ce site…