linuxfr.org Draft: Prochaine version de LinuxFr avec Rails7

Je crée cette pull request en brouillon pour suivre le plan de ce commentaire.

Hello,

J'ai regardé en vitesse les premiers fichiers et ça à l'aire bien (decaffeinate semble avoir bien marché, merci pour l'ajout des commits avec les fixes des suggestions).

Comme il y a beaucoup de changements tout comme la migration de rails prévue par @echarp, ça va demander beaucoup de temps pour tester.

Je propose de fusionner les 2 développements ensemble et de ne faire les tests qu'une seul fois sur tout le site.

Le plan serait de:

[x] Créer une branche "rails-7" depuis la master actuelle
[x] Fusionner la PR #378 dans celle-ci
[x] Fusionner la PR #375
[x] Fusionner ma branche qui met à jour les Dockerfile pour Ruby 3 / Rails 7
[x] Publier une nouvelle version de board-linuxfr avec la mise à jour de Goliath (~~je vais publier sur le repository de Github~~ j'ai publié sur rubygems.org avec le nom board-sse-linuxfr.org) pour que ça fonctionne avec Ruby 3
[x] Ajouter un commit pour utiliser cette nouvelle version de board-linuxfr dans les Docker
[x] Corriger l'insertion des images pour utiliser le service img-linuxfr (la méthode wikify ne semble plus fonctionner, les images des liens restent sur la source)
[x] Utiliser par défaut le port 9000 pour ne plus avoir besoin de CAP réseau élevée (#395)
[ ] Mettre à jour le fichier INSTALL.md
[ ] Faire le merge sur master (ou au moins faire un rebase et geler master)
[ ] Installer tout ça sur le domaine alpha.linuxfr.org
[ ] Demander aux différents acteurs de tester (admin, animateur, moderateur, mainteneur, visiteur) sur cette instance.

Mar 08 '24 15:03 Trim

Pour la publication de la gem board-linuxfr sur Github Package Repository, j'ai réussi, mais c'est inutile: pour pouvoir télécharger la gem, il faut être connecté à Github, même si la gem est publique. Apparemment, Github ne compte pas changer ça.

Comme on n'a pas prévu de passer à Gitlab (qui sait faire ça, en tout cas pour node), je vais demander à Bruno les accès aux gems sur rubygems.org.

Mar 10 '24 12:03 Trim

J'ai publié aujourd'hui la nouvelle version de la gem board-linuxfr sous le nom de board-sse-linuxfr.org sur rubygems.org

J'avais essayé le Github Package Repository, mais on n'est obligé d'avoir un token Github pour télécharger la gem, même si elle est publique. C'était donc inutile :-1:

J'ai mis à jour les fichiers container pour utiliser cette nouvelle gem et nouvelle version.

Enfin, j'ai rebasé la branche sur master pour récupérer les derniers changements fusionnés ces dernières semaines.

J'ai voulu contrôler que les nouvelles fonctionnalités pour "les images externes bloquées" fonctionnent encore, mais j'ai l'impression qu'il y a un soucis avec le pipeline qui transforme le markdown en HTML (le tag src des balises <img> n'est pas mis à jour et les images n'apparaissent pas dans la liste des "images externes").

J'ai donc ajouté une tâche pour fixer ça avant de pousser sur alpha.

J'ai profité d'ajouter une deuxième tâche pour exécuter par défaut sans privilège root/réseau LinuxFr.

[ ] Corriger l'insertion des images pour utiliser le service img-linuxfr (la méthode wikify ne semble plus fonctionner, les images des liens restent sur la source)

[ ] Utiliser par défaut les ports 8080 et 4443 pour ne plus avoir besoin de CAP réseau élevée

Mar 22 '24 21:03 Trim

Ouf, ce n'était pas le pipeline de Markdown vers HTML qui était à modifier, mais juste le modèle Image qui utilisait la méthode URI.encode (alias URI.escape) qui n'existe plus en Ruby 3.

Mar 23 '24 00:03 Trim

Aujourd'hui, j'ai mis à jour le fichier docker-compose.yaml de la branche master pour inclure les commandes healthchek qui vérifient l'état des services.

J'ai aussi mis à jour sur la branche master les Dockerfile pour ne plus utiliser Debian Stretch, parce que j'y avais un problème qui m'empêchait d'exécuter correctement npm ci pour installer les dépendances (le processus ne rendait jamais la main). Tant qu'à faire, je les ai moderniser directement (les commandes RUN avec le bash "strict mode").

Du coup, pour la branche rails7, j'ai donc fait un rebase depuis master pour être à jour avec l'état de master (pour les déploiements avec container). Quelques commits qui modernisaient les Dockerfile/Containerfile ont disparu, parce qu'ils avaient déjà été backportés dans master.

J'ai ajouté aussi quelques commits sur la branche rails7 pour:

faire en sorte que le service linuxfr-img utilise Debian Bookworm pour exécuter le service img-Linuxfr.org écrit en go
Réintégrer explicitement nodejs qui est nécessaire pour uglify les codes javascripts

Pour ce dernier point, LinuxFr n'a pas beaucoup de JavaScript et les moteurs modernes sont très efficaces pour avoir du code très réactif. Est-ce que vous pensez vraiment que c'est encore nécessaire ?

Je serai pour enlever la gem uglifier et donc nodejs et servir directement le JavaScript. Ça sera plus proche de la philosophie open source, car le code source sera lisible depuis la console JavaScript.

Mar 24 '24 20:03 Trim

Bonne idée. Moins de dépendance c'est mieux!

Mar 24 '24 20:03 echarp

Je serai pour enlever la gem uglifier et donc nodejs et servir directement le JavaScript. Ça sera plus proche de la philosophie open source, car le code source sera lisible depuis la console JavaScript.

Alors, j'ai essayé dans ma branche remove-nodejs-and-uglifier et en fait la taille a pas mal grossi, parce qu'on inclus jQuery v2.

Comme uglifier supprime les fonctions non utilisées de jQuery, il est quand même capable de bien réduire la taille totale de JavaScript à télécharger (230 Ko de moins).

Pour comparaison, voilà la taille du fichier JavaScript généré pour les 3 environnements:

Description	Branche rails7	Branche remove-nodejs-and-uglifier	Production actuelle (ruby 2)
Taille JS (kio)	~KO~ 145Ko (**)	370 Ko	147 Ko

(**): J'ai forcé l'utilisation de ~uglifier~ terser dans config/environments/develop.rb pour ce test ~, mais uglifier n'est pas compatible avec EcmaScript 6 et decaffeinate a justement fait des scripts au format EcmaScript 6.~ (terser est compatible avec EcmaScript 6).

@oumph: si on enlève uglifier + nodejs de la stack, le fichier application.js grossis de 230Ko, est-ce que ce serait un problème pour la bande passante ?

Mar 27 '24 16:03 Trim

Pour info, jquery ui est très utile? :-)

Mar 27 '24 18:03 echarp

J'ai jeté un coup d'œil rapide, a priori il s'agit de jQuery avec jquery_ujs, c'est un peu indispensable en l'état :)

Zut zut, je pensais qu'on pourrait simplifier cette partie là.

Alors on peut envisager une autre direction: l'uglification se fait au moment de la précompilation des assets. On peut faire cette précompilation ailleurs que sur le serveur de prod. Et dans ce cas les assets précompilés peuvent être mis dans git ou poussés avec un autre mécanisme genre rsync... Je ne suis pas sûr que ça simplifie beaucoup.

Mar 27 '24 18:03 echarp

J'aurai voulu enlever jquery, parce qu'on utilise une version majeur obsolète (v2 au lieu de v3) et parce qu'avec JavaScript moderne on peut faire plein de choses sans jquery.

Mais ça sera un projet complet, parce que c'est jquery qui fait l'éditeur Markdown actuel de LinuxFr :)

Pour l'instant, l'uglifier ne fonctionne plus avec la branche rails7 et donc le seul choix est de livrer le JavaScript avec 200Ko de plus.

Ce n'est pas non plus la mer à boire de nos jours ces 200Ko de plus 🙂

Si ce n'est pas ok pour l'hébergement, alors j'investirais plus de temps pour voir s'il y aurait une autre gem qui minifie et qui est compatible EcmaScript 6 (je crois en avoir vu un dans une des documentations que j'ai lu récemment).

Par contre, ce qui est bien, c'est que Nodejs ne devrait pas être un pré-requis pour l'environnement de dev, parce que uglifier y est désactivé pour pouvoir debugger.

Mar 27 '24 18:03 Trim

Si ce n'est pas ok pour l'hébergement, alors j'investirais plus de temps pour voir s'il y aurait une autre gem qui minifie et qui est compatible EcmaScript 6 (je crois en avoir vu un dans une des documentations que j'ai lu récemment).

Ah je viens de tester terser pour remplacer la gem uglifier et ça fonctionne très bien et redonne une taille de 145Ko. Je met ce changement sur la branche rails7 en attendant de voir si on enlève complètement nodejs et la minisation du code javascript.

Mar 27 '24 20:03 Trim