Il s’agit d’une installation Discourse standard et autonome, tentant une mise à niveau de v2.7.0.beta1 vers v2.7.0.beta2
L’échec se produit ici :
uglifyjs '/var/www/discourse/public/assets/_vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js' -m -c -o '/var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js' --source-map "base='/var/www/discourse/public/assets',root='/assets',url='/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js.map'"
Erreur de syntaxe à _vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js:1850,34
return Handlebars.compile(...arguments);
^
ERREUR : Token inattendu : punc «.»
at JS_Parse_Error.get (eval at <anonymous> (/usr/lib/node_modules/uglify-js/tools/node.js:18:1), <anonymous>:71:23)
at fatal (/usr/lib/node_modules/uglify-js/bin/uglifyjs:394:27)
at run (/usr/lib/node_modules/uglify-js/bin/uglifyjs:343:9)
at Object.<anonymous> (/usr/lib/node_modules/uglify-js/bin/uglifyjs:259:5)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:831:12)
rake aborted!
Errno::ENOENT : Aucun fichier ou répertoire du type @ rb_file_s_size - /var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js
/var/www/discourse/lib/tasks/assets.rake:287:in `size'
/var/www/discourse/lib/tasks/assets.rake:287:in `block (4 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:178:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:278:in `block (3 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:269:in `each'
/var/www/discourse/lib/tasks/assets.rake:269:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:178:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:266:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tâches : TOP => assets:precompile
(Voir la trace complète en exécutant la tâche avec --trace)
Docker Manager : ÉCHEC DE LA MISE À NIVEAU
Des idées ? Le site est hors ligne en conséquence. Merci.
root@redmine:/var/discourse# ./launcher enter app
ls -al ls -al root@xxxxx-app:/var/www/discourse# ls -al /var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js
-rw-r--r-- 1 discourse www-data 659907 Jan 22 04:55 /var/www/discourse/public/assets/vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js
Merci… absolument aucun plugin ni personnalisation lourde… c’était essentiellement une installation fraîche fin 2020, avec seulement de légers ajustements des paramètres via l’interface d’administration pour des éléments comme les permissions des modérateurs, etc. Très étrange.
Malheureusement, je n’ai pas pris de sauvegarde avant d’exécuter la mise à niveau, bien que j’en aie quelques-unes automatisées datant de quelques jours. Je suppose que c’est ma seule issue pour l’instant… n’ayant pas l’esprit Ruby, je ne sais pas comment résoudre cette erreur.
Ah, il semble que l’exécution de ./launcher restart app ait au moins permis de le remettre en ligne, malgré les mises à jour du schéma de base de données qui ont été appliquées. Avant cela, il renvoyait une erreur 500. Ouf.
Voici ce qui se trouve dans le répertoire des plugins. Je suppose qu’ils ont été fournis avec l’installation de base, car je n’en ai ajouté aucun manuellement.
root@redmine-app:/var/www/discourse# ls -al plugins/
total 12
drwxr-xr-x 22 discourse discourse 4096 Nov 4 04:54 .
drwxr-xr-x 56 discourse discourse 4096 Jan 22 04:55 ..
drwxr-xr-x 13 discourse discourse 43 Nov 4 04:54 discourse-details
drwxr-xr-x 16 discourse discourse 54 Nov 4 04:54 discourse-local-dates
drwxr-xr-x 20 discourse discourse 69 Jan 22 04:55 discourse-narrative-bot
drwxr-xr-x 11 discourse discourse 59 Nov 4 04:54 discourse-presence
drwxr-xr-x 19 discourse root 4096 Jan 22 04:43 docker_manager
drwxr-xr-x 4 discourse discourse 51 Sep 28 05:11 lazy-yt
drwxr-xr-x 25 discourse discourse 99 Nov 4 04:54 poll
drwxr-xr-x 8 discourse www-data 129 Nov 4 04:54 styleguide
Le thème du site est un peu cassé après le redémarrage, probablement parce que les assets n’avaient pas fini de compiler… Je me demande s’il existe un moyen de terminer le processus manuellement.
Voici la section du fichier JS du fournisseur sur laquelle il y a une erreur :
// permet de l'importer comme module
if (typeof define !== "undefined") {
define("handlebars", ["exports"], function (__exports__) {
// Il se peut qu'il ne soit pas défini côté serveur, ce qui est acceptable pour pretty-text
if (typeof Handlebars !== "undefined") {
// eslint-disable-next-line
__exports__.default = Handlebars;
__exports__.compile = function () {
// eslint-disable-next-line
return Handlebars.compile(...arguments);
};
}
});
define("handlebars-compiler", ["exports"], function (__exports__) {
// eslint-disable-next-line
__exports__.default = Handlebars.compile;
});
}
;
La ligne 1850 (celle qui génère l’erreur) est ce morceau :
return Handlebars.compile(...arguments);
Existe-t-il une astuce temporaire que je pourrais appliquer ici pour contourner le problème ? Ou ce fichier sera-t-il généré à chaque tentative de mise à niveau ? (P.S. : après le redémarrage, le système pense que la mise à niveau est complète… mais le thème est cassé. Je me demande si je peux passer cette étape d’une manière ou d’une autre, ou si je devrai restaurer depuis une sauvegarde, en gros…)
OK – alors je ne sais pas pourquoi, mais j’ai exécuté le processus de mise à jour manuelle (git pull; ./launcher rebuild app) et cela a fonctionné.
Beaucoup d’autres activités, comme les mises à jour de PostgreSQL, etc., ont été effectuées dans le cadre de cette mise à jour manuelle.
Mon hypothèse : quelque chose dans ce commit ci-dessus n’était pas compatible avec uglify-js ou la version de Rails, ou autre chose, sur le conteneur d’origine. C’était essentiellement une mise à jour qui nécessitait le processus de mise à jour « manuel ».
Comme l’interface d’administration web m’a permis de mettre à jour docker_manager puis l’application Discourse elle-même, j’ai supposé que cela ne serait pas nécessaire (je sais que parfois il indique qu’une mise à jour via l’interface d’administration web ne peut pas être effectuée et qu’il faut le faire manuellement… mais ce n’est pas arrivé dans ce cas, et cela aurait probablement dû l’être…)
J’ai aussi rencontré un problème lors de l’exécution de cette mise à jour (mise à jour Web)
Après avoir exécuté ces commandes :
cd /var/discourse
git pull
./launcher rebuild app
Discourse fonctionne, mais il n’est pas possible d’accéder au panneau d’administration (/admin).
Une mise à jour d’Ubuntu a permis de rétablir le fonctionnement.
L’annonce indiquait qu’il fallait effectuer une reconstruction en ligne de commande. Je ne suis pas sûr de savoir pourquoi l’interface web n’a pas su imposer cette exigence.
Curieusement, je tentais justement d’utiliser cette fonctionnalité en développement et cela ne fonctionne pas pour moi… L’objet Handlebars ne possède que create(), pas compile(), bien que je puisse me tromper de piste… J’ai soulevé le sujet ici : Adding a bespoke raw template
