Draft: Prochaine version de LinuxFr avec Rails7 #383
Conversation
|
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. |
|
J'ai publié aujourd'hui la nouvelle version de la gem 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 👎 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 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.
|
|
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 |
Dépendant de la gemme rails-sass-images qui n'est plus développée
l'évolution de la gemme
Ajout de "optional: true" pour les modèles qui permettent une valeur "null". Document du comportement belongs_to: https://sipsandbits.com/2015/09/21/whats-new-in-rails-5/#belongs_toisrequiredbydefault
Il y avait deux classes pour dynamiquement chercher des templates entre les espaces de rédaction et modération, après tests et recherches il semble que ça ne soit pas (ou plus?) nécessaire.
les espaces de rédaction et modération
Tests et validations nécessaires, mais en pause car migration vers 7 prévue
…s non fonctionnelles
La méthode est maintenant nommée File.exist?
qui sont à peu près touts couverts
(en tous cas du code testé d'après la gemme simplecov...)
Image caching were not working because the Image model silently decided all image were "internal": the URI.encode (aka URI.escape) method does not exist anymore in Ruby 3, which raised an error which where ignored by the "rescue" line. Instead of doing "URI.parse(URI.encode(str))", we are just doing "URI.join(str)", because the join method converts firt the str to RFC3986. As this method does not raise error, the "rescue" part has been removed too.
|
Aujourd'hui, j'ai mis à jour le fichier J'ai aussi mis à jour sur la branche Du coup, pour la branche J'ai ajouté aussi quelques commits sur la branche
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 |
|
Bonne idée. Moins de dépendance c'est mieux! |
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:
(**): J'ai forcé l'utilisation de @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 ? |
|
Pour info, jquery ui est très utile? :-) |
|
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. |
|
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. |
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 |
The minimization of JavaScript files is useful, because LinuxFr.org includes jQuery and jQeury UI and certainly don't use all the tools provided by them. The decaffeinate process to build JavaScript files from old coffee script files has built EcmaScript 6 files. As uglifier is not compatible with EcmaScript 6, it has been replaced by terser which is recommended by the uglifier project itself.
La nouvelle version supprime quelques helper, dont `list_of` qui était utilisée ici et là et qui est maintenant rajoutée dans `application_helper`. Méthodes supprimées: block_is_haml?, capture_haml, escape_once, find_and_preserve, flatten, haml_concat, haml_indent, haml_tag, haml_tag_if, html_attrs, html_escape, init_haml_helpers, is_haml?, list_of, non_haml, precede, succeed, surround, tab_down, tab_up, with_tabs Référence: https://github.com/haml/haml/releases/tag/v6.0.0
Still maintained, will require an upgrade to dart-sass at some point.
Upgrade haml and sass
This commit updates several gem dependencies in the Gemfile and Gemfile.lock, including Rails and related gems. The version constraint for the sitemap_generator gem has been removed, allowing the latest version to be used. The sitemap configuration has been updated to match the new usage of sitemap_generator. The encoding comment and an extra line have been removed, and the `add_links` method has been replaced with `create`. Extra lines have been added before `sitemap.add` calls for readability.
feat: Update gem dependencies and sitemap generator
|
Quand j'ai configuré une nouvelle machine, j'ai ce message d'avertissement à la création des bases de données:
|
This commit introduces two new global constants MY_PUBLIC_URL and IMG_PUBLIC_URL which should be used now to build URLs. For alpha and production Ruby environments, they are fixed with their real values directly in the `config/environments/*.rb` files. For the development Ruby environment, they are defined by default to `http://dlfp.lo` and `http://image.dlfp.lo`. You can customize either by updating the `config/environments/development.rb` file or by setting the *process* environment variables `DOMAIN`, `DOMAIN_HTTP_PORT`, `IMAGE_DOMAIN` and `IMAGE_DOMAIN_HTTP_PORT`. For containers, you can set these variables in the `deployment/default.env` file.
|
Quand je lance les tests, j'ai aussi ces avertissements:
|
allow to use custom HTTP public port to permit rootless run
|
Le warning nokogiri semble être lié à des dépendances intermédiaires. À voir si ça évolue avec les mises à jour. Pour les credentials, c'est une autre évolution de rails, qui sont passés sur un autre mécanisme de stockage des secrets. Comme on utilise, il me semble, des variables d'environnement passées par le serveur web, on devrait pouvoir remplir sans utiliser... ou quelque chose de plus approprié, à voir ce qu'on veut faire. |
|
Le 22 septembre 2024 23:14:33 GMT+02:00, echarp ***@***.***> a écrit :
Le warning nokogiri semble être lié à des dépendances intermédiaires. À voir si ça évolue avec les mises à jour.
Oui, j'ai vu, ça semble venir de sanitizer 5 qui est installé par notre outil html-pipeline-linuxfr. On peut mettre à jour notre outil pour passer à sanitizer 6 qui a mis à jour nokogiri.
Comme sanitizer fait un job assez critique, j'aimerai bien le mettre à jour en même temps que rails.
Pour les credentials, c'est une autre évolution de rails, qui sont passés sur un autre mécanisme de stockage des secrets. Comme on utilise, il me semble, des variables d'environnement passées par le serveur web, on devrait pouvoir remplir sans utiliser... ou quelque chose de plus approprié, à voir ce qu'on veut faire.
J'ai essayé de regarder hier et je crois qu'on l'utilise pour générer des secrets aléatoires au démarrage du service. Après, ça ne bloque pas cette mise à jour, ça sera à penser pour la mise à jour vers rails 7.2.
|
Alors je me suis trompé, les valeurs sont fixes pour les environnements development et tests. Comme tu l'as relevé, ce sont des variables d'environnement pour la production. J'ai lu un peu la documentation du nouveau système et c'est intéressant parce que:
Cette évolution est à réfléchir, je ne sais pas si elle est souhaitée par les admins de LinuxFr. On pourra le faire dans un second temps en se coordonnant avec eux. |
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:
je vais publier sur le repository de Githubj'ai publié sur rubygems.org avec le nomboard-sse-linuxfr.org) pour que ça fonctionne avec Ruby 39000pour ne plus avoir besoin de CAP réseau élevée (allow to use custom HTTP public port to permit rootless run #395)INSTALL.md