Introduction des ressources JS précompilées pour les auto-hébergeurs

Annonces
1

:mega: Discourse publie désormais des actifs JavaScript précompilés, ce qui accélérera considérablement l’installation et les mises à jour, en particulier pour les serveurs disposant de ressources limitées.

La compilation et l’optimisation des actifs JavaScript ont toujours été l’une des parties les plus gourmandes en ressources de l’exécution de Discourse. Au fur et à mesure que notre base de code et l’écosystème JavaScript ont évolué, ce processus est devenu encore plus exigeant.

Lors de nos tests, ces changements réduisent le temps de construction des actifs sur une instance Digital Ocean de 1 Go de RAM de 45 minutes à seulement 3 minutes.

Comment ça marche ?

À chaque commit fusionné dans main, un workflow GitHub Actions construit et regroupe les actifs dans des fichiers .tar.gz (un pour la production, un pour le développement). Ces bundles sont publiés via les releases GitHub dans un dépôt dédié. Nous nous assurons que les actifs sont publiés avant que tout commit ne passe à tests-passed.

Lors de la construction de votre propre site, Discourse recherche désormais un bundle précompilé correspondant et le télécharge. Les plugins sont ensuite construits par-dessus. Si aucun bundle n’est trouvé ou s’il y a une erreur, Discourse revient à la construction à partir des sources.

Cela a-t-il un impact sur les utilisateurs finaux ?

Non. Les actifs sont toujours servis aux utilisateurs finaux depuis votre propre serveur / CDN.

Puis-je refuser ?

Oui ! Si vous préférez construire vos propres actifs et disposez d’un serveur suffisamment puissant, définissez DISCOURSE_DOWNLOAD_PRE_BUILT_ASSETS: 0 dans votre fichier app.yml.

Que se passe-t-il si j’exécute une version forkée ou patchée de Discourse ?

Les bundles d’actifs sont nommés par le hash du commit. Si vous exécutez un fork, aucun bundle ne sera trouvé et les actifs seront construits à partir des sources. Si votre copie de Discourse est patchée (c’est-à-dire que la zone de travail git n’est pas propre), Discourse ne tentera pas de télécharger un bundle.

Qu’en est-il des autres étapes de construction liées aux actifs ?

Actuellement, cette optimisation s’applique uniquement aux actifs JS principaux. À l’avenir, nous pourrions l’étendre à certains plugins et à d’autres étapes comme la compression gz/brotli.

Qu’en est-il de la branche stable ?

Les actifs précompilés pour la branche stable seront publiés à partir de la prochaine mise à jour majeure de version, prévue pour août 2025.

53 « J'aime »
2

Je viens de reconstruire https://discourse-on-a-pi5.falco.dev/ et cela n’a pris que 3 minutes et 35 secondes, c’est très impressionnant !

23 « J'aime »
3

Configuration de deux conteneurs et sans base de données ~8 minutes.

5 « J'aime »
4

Whoa :scream: :person_bowing:

Je n’ai pas cette option dans ma configuration, dois-je l’ajouter avec la valeur 1 pour pouvoir y participer ? Ou tout cela se produira-t-il comme par magie lors de ma prochaine mise à jour ?

5

FYI voici ce qui se passe lorsque votre installation ne répond pas aux critères :

I, [2025-08-01T06:43:09.560655 #1]  INFO -- : cd /var/www/discourse && su discourse -c 'bundle exec rake assets:precompile:build'
[assemble_ember_build] La limite de taille du tas Node.js est inférieure à 2048 Mo. Définition de --max-old-space-size=2048 et CHEAP_SOURCE_MAPS=1
[assemble_ember_build] Aucun fichier d'informations de build existant trouvé.
[assemble_ember_build] Le répertoire de travail Git n'est pas propre. Impossible de télécharger les ressources précompilées.
[assemble_ember_build] Exécution du build principal complet...

J’apporte quelques modifications à config/initializers/100-sidekiq.rb dans app.yml pour ajouter la prise en charge d’un nombre de tentatives pour tous les jobs sidekiq (ce qui est, je présume, la seule façon d’y parvenir et non dans un plugin ? Mais je pourrais y revenir) donc je pense que cela suffit à ne pas répondre aux critères…

2 « J'aime »
6

Elle est activée par défaut. Vous n’avez besoin de spécifier la configuration que si vous souhaitez vous désactiver.

Oui, exactement. Tout type de différence dans le dépôt git le fera échouer.

Concernant le sidekiq, si vous ouvrez un sujet à ce sujet, je suis sûr que nous pourrons trouver un moyen de le faire soit à partir d’un plugin, soit nous pourrions introduire un nouveau GlobalSetting pour cela.

4 « J'aime »
7

soit dit en passant, une façon très simple de chronométrer vos builds sans avoir à rester présent à votre console est la suivante :

time ./launcher rebuild app
11 « J'aime »
8

Bon changement. J’obtiens un

real 2m41.898s
user 0m0.372s
sys 0m0.583s

Merci pour votre travail.

4 « J'aime »
9

Impressionnant. La date a-t-elle été définie ? Ma version est a81eaacb1c53581912519ae6574fa3523ef215dd. Dois-je attendre pour reconstruire ?

10

Oh bien :star_struck:

Merci pour ça @merefield - Je n’arrive pas à croire que je ne découvre cela que maintenant après 7 ans et plusieurs centaines de reconstructions en ligne de commande :grin:

5 « J'aime »
11

Si vous suivez notre canal de publication standard, vous pouvez reconstruire dès maintenant et profiter des avantages.

4 « J'aime »
12

Les seuls ! Merci.

1 « J'aime »
13

4 minutes pour reconstruire J’ai fait cela quelques fois aujourd’hui, migration complète ! Impressionnant Discourse ! La prochaine reconstruction, je me souviendrai d’utiliser cette magnifique commande merci à tous.

1 « J'aime »
14

Peut-être serait-il judicieux de limiter cela à app/assets, config/locales pour le cœur et les plugins ? Actuellement, cela provoquera également une reconstruction complète lorsque des correctifs uniquement en Ruby (sécurité) auront été appliqués.

15

Oui, il est possible de restreindre davantage. Cependant, dans le cas des correctifs de sécurité, il est assez courant qu’ils affectent également l’application JS… donc une reconstruction complète sera toujours nécessaire.

2 « J'aime »
16

Je viens de l’essayer, c’est fantastique, ~3min ! Quelle fonctionnalité intelligente et incroyable. :star_struck:
Cela me donne envie d’installer tous les plugins existants un par un maintenant. :rofl:

5 « J'aime »
17

Vraiment vraiment, c’est génial

18

En fait, je pense que cela irait à l’encontre de son objectif, si je comprends bien.

Vous voyez, il ne peut utiliser que les ressources compilées pour le code de base groupé (et cela explique en grande partie la récente décision de grouper les plugins de base populaires, d’ailleurs !)

Il doit compiler et grouper tous les plugins « inconnus » lors de la compilation, donc beaucoup d’entre eux le ralentiraient considérablement.

2 « J'aime »
19

Mise à jour vers 3.6.0.beta1 et les ressources précompilées sont introuvables

Fetching and extracting https://get.discourse.org/discourse-assets/3.6.0.beta1-d63a2431/production.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100     9  100     9    0     0     24      0 --:--:-- --:--:-- --:--:--    24
curl: (22) The requested URL returned error: 404
[assemble_ember_build] Failed to download prebuilt assets: Command failed with exit 22: curl
[assemble_ember_build] Running full core build...
2 « J'aime »
20

Ciblez-vous la balise beta pour cette installation ?