Dans le footer, le lien Licence pourrait plutôt être À propos ou Infos légales, non ? De plus, on pourrait confondre avec la licence Ğ1.
La page Qui sommes-nous semble un peu périmée. Je n’ai jamais entendu parler de « Art et Zerty », et plusieurs assos existent autour de la ML et Duniter.
Sur la page de la licence Ğ1, il y a un problème de markdown, un /!\ qui pourrait être remplacé par un , des URL à formater en lien, et un alignement centré qui n’est pas très joli…
Non elle n’est pas périmée, Duniter appartient toujours à la société de cgeek. Nous projetons de créer une association officielle pour porter le projet Duniter, mais elle n’existe pas encore.
Aucune des assos existantes n’héberge juridiquement le projet Duniter.
Oui, bien sûr, le contenu est du “placeholder” pour l’instant. Et je pense solliciter chacun pour écrire un petit paragraphe sur lui parce que je ne serais pas capable de dire précisément ce que chacun a fait.
J’ai un peu laissé traîner le sujet, mais je pense que le site est prêt à passer en production. Il y a encore du travail pour l’améliorer et le compléter, mais je ne vois pas de perte de fonctionnalité notable par rapport à l’existant.
Pour le déploiement, ma solution préférée est un rsync vers le serveur de production après revue locale des modifications. Je propose d’héberger moi-même le site auquel cas j’aurais juste besoin que duniter.org pointe vers mon serveur, par exemple avec les enregistrements DNS suivants :
@ 10800 IN A 51.158.116.127
@ 10800 IN AAAA 2001:bc8:630:2313::1
Si certaines personnes s’y opposent formellement, j’aurais besoin d’aide pour mettre en place la CI.
Je vais lancer une petite campagne d’évaluation auprès des utilisateurs du site sur le forum monnaie libre sur la version actuelle du site en preview sur http://duniter.trentesaux.fr/
Je suis opposé à l’hébergement des services du projet Duniter sur un serveur personnel.
Je suis pour la mise en place d’une CI/CD pour que tous les contributeurs du dépôt aient le contrôle sur le déploiement sans nécessiter d’accès ssh au serveur.
Je peux te guider et t’aider si tu bloques pour mettre en place la CI/CD. J’aimerais y participer, mais j’ai clairement pas le temps de m’en occuper.
Tu peux prendre inspiration de ce dépôt pour construire des images Zola. Et de cette méthode de déploiement qui doit être élaborée pour construire le site web avec Zola.
☐ intégrer automatiquement la documentation de duniter depuis le gitlab
☐ traduire la documentation en français pour les utilisateurs non-anglophones
☐ prendre en compte les suggestions esthétiques et pratiques
J’espère que le site sera prêt pour la campagne de test de duniter_v1.9…
Du temps ce n’est pas le mot, disons plutôt que quand j’ai vu ton post et la réponse de moul j’ai considéré qu’il était plus prioritaire de consacrer cette soirée à t’aider sur la CI/CD plutôt qu’à coder sur Duniter
Nous n’avons toutefois pas parlé du basculement sur duniter.org, on ne le fera que quand on considérera que le site sera prêt à remplacer définitivement l’ancien. J’ai voulu regarder comment c’est fait pour préparer le terrain et pour le moment c’est géré par norstorm, il faudrait dabord migrer le vhost nginx sur doppler, mais cela va avoir un impact sur le site anglais, la CI/CD du site anglais n’a jamais fonctionné, je ne comprends pas comment fonctionne son déploiement actuellement, @Moul des infos ?
Du coup il faut migrer ces webhook sur doppler ou écrire une CI/CD pour le site anglais. Mais je n’y connais rien à Pelican et ne sais pas non plus comment installer ce webhook sur doppler, là je suis coincé, je ne peux pas faire la migration, qui sais faire ça ?
Pour ma part, je laisserai tomber les webhook.
Je construirais les fichiers statiques du site web dans une image docker, puis ça serait distribué sur GitLab Pages. Puis, il faut mettre en place un vhox comme pour https://silkaj.duniter.org.
Les deux sites web peuvent rester en parallèle avec leurs modes de fonctionnement et déploiement.
Non ils ne peuvent pas sans rien faire car le domaine duniter.org ne peut pointer que sur une seule IP. Actuellement il pointe sur norstorm, or il faut qu’il pointe sur doppler pour que le nouveau site fr soit servi, donc le site anglais ne marchera plus, tu comprends le problème ?
Non en vrai je ne souhaite pas migrer le weebhook, je n’ai jamais touché à Ansible et les liens que tu me donnes ne m’aident pas, je n’ai aucune idée de ce que je suis censé faire avec ça, je n’ai pas les compétences pour migrer un webhook
En plus il y a de toute façon un autre problème qui fait que l’on ne peut pas garder le fonctionnement actuel avec le site français sur l’url duniter.org/fr: @HugoTrentesaux à conçu le nouveau site d’une manière qui nécessite impérativement que le site soit à la racine (sans path), donc ça ne peut pas fonctionner sous /fr.
Créer une redirection duniter.org/fr -> duniter.fr
Et pour le site anglais deux possibilités :
Soit on le migre sur duriter.org avec une redirection duniter.org/en -> duniter.org
Soit on le laisse sur Duniter | Home avec une redirection duniter.org -> duniter.org/en
Étant donné que duniter.fr n’est plus et redirige déjà sur duniter.org, il suffirait de modifier la zone dns de duniter.fr pour le faire pointer sur doppler et derrière je peut m’occuper de créer la conf nginx pour le nouveau site français
Je crois me souvenir que c’est @kimamila qui gère le domaine duniter.fr, c’est bien ça ? @kimamila est-ce que cette proposition te conviens ?
profite du système de cache de zola pour éviter de faire les requêtes à chaque fois lors du développement
Inconvénients :
ne profite pas de la coloration syntaxique à la compilation faite par zola
les liens internes ne fonctionnent pas car ils pointent vers des fichiers .md
Je vais chercher à mettre en place une solution maison qui résout ces problèmes (probablement un script python), mais en attendant on a une solution quasi fonctionnelle et très facile.
pour profiter de la coloration syntaxique, il vaut mieux utiliser la syntaxe ``` suivie du langage pour le code, plutôt que l’indentation simple. Ce serait plus simple de faire ce changement directement sur le Gitlab.
je n’ai pas blindé le script (pas de gestion d’erreur), il reste à améliorer ou à utiliser avec précaution.
il y a deux options pour utiliser le script : soit on exécute le script localement et on commit les modifications de la doc, soit on garde les fichiers vides (seuls les en-têtes sont commités) et on laisse le script écraser le contenu à chaque compilation. Dans le deuxième cas, il reste à déclencher la CI à chaque mise à jour de la documentation distante.
Oui c’est déjà ce que je fais, sauf s’il s’agit d’une simple commande bash seule.
Il ne faut pas commit, c’est très moche, le contenu doit être généré par la CI,
Pourquoi faire compliqué quand on peut faire simple, il suffit de créer une schedule pipeline qui s’exécute toute les 24h, je viens de le faire, le site sera désormais mis à jours automatiquement tout les jours à 1h du matin
En tout cas félicitations ça semble bien fonctionner