Dies ist eine standardmäßige, eigenständige Discourse-Installation, die versucht, von v2.7.0.beta1 auf v2.7.0.beta2 zu aktualisieren.
Der Fehler tritt hier auf:
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'"
Parse error at _vendor-b631d4ab0775fdbe453aa2158e18dc41826d0ba619e5f2731e5b9fa4c458af99.js:1850,34
return Handlebars.compile(...arguments);
^
ERROR: Unexpected token: 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: No such file or directory @ 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>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
Docker Manager: FAILED TO UPGRADE
Haben Sie eine Idee? Die Website ist dadurch offline. Danke.
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
Danke… absolut keine Plugins oder aufwendigen Anpassungen… es war im Grunde eine frische Installation Ende 2020, nur kleine Änderungen an den Einstellungen über die Admin-Oberfläche für Dinge wie Moderatorrechte usw. Sehr seltsam.
Leider habe ich kein Backup erstellt, bevor ich das Upgrade durchgeführt habe, obwohl ich einige automatisierte Backups von vor ein paar Tagen habe. Ich schätze, das ist vorerst mein einziger Ausweg… da ich mich nicht mit Ruby auskenne, habe ich keine Ahnung, wie ich diesen Fehler herausfinden soll.
Ah, sieht so aus, als hätte ./launcher restart app es trotz der durchgeführten Datenbank-Schema-Updates zumindest wieder online gebracht. Zuvor warf es einen 500-Fehler. Pfui!
Das sind die Inhalte im plugins-Verzeichnis. Ich gehe davon aus, dass sie mit der Core-Installation kamen, da ich keine manuell hinzugefügt habe.
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
Das Seitenthema ist nach dem Neustart etwas kaputt, wahrscheinlich weil die Assets noch nicht vollständig kompiliert waren. Ich frage mich, ob es einen Weg gibt, das manuell abzuschließen.
Dies ist der Abschnitt in der Vendor-JS-Datei, der Probleme verursacht:
// allow us to import this as a module
if (typeof define !== "undefined") {
define("handlebars", ["exports"], function (__exports__) {
// It might not be defined server side, which is OK for 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;
});
}
;
Zeile 1850 (wo der Fehler auftritt) ist dieser Teil:
return Handlebars.compile(...arguments);
Gibt es einen vorübergehenden Workaround, den ich hier anwenden könnte, um das Problem zu umgehen? Oder wird diese Datei bei jedem Upgrade-Versuch neu generiert? (P.S.: Nach dem Neustart denkt das System, ich hätte das Upgrade vollständig abgeschlossen, aber das Theme ist kaputt. Ich frage mich, ob ich diesen Schritt irgendwie überspringen kann oder ob ich von einem Backup wiederherstellen muss, im Grunde genommen…)
OK – also ich weiß nicht warum, aber ich habe den manuellen Upgrade-Prozess ausgeführt (git pull; ./launcher rebuild app) und es hat funktioniert.
Viele andere Aktivitäten wie PostgreSQL-Upgrades usw. wurden im Rahmen dieses manuellen Upgrades durchgeführt.
Meine Vermutung: Etwas in dem oben genannten Commit war nicht mit uglify-js oder der Rails-Version oder irgendetwas anderem im ursprünglichen Container kompatibel. Es war im Grunde ein Upgrade, das den ‘manuellen’ Upgrade-Prozess erforderte.
Da mir die Web-Admin-Oberfläche erlaubte, docker_manager und dann die Discourse-App selbst zu upgraden, ging ich davon aus, dass dies nicht notwendig sein würde (ich weiß, dass es manchmal heißt, ein Upgrade über die Web-Admin-Oberfläche sei nicht möglich und manuell durchzuführen… aber das ist in diesem Fall nicht passiert, und hätte wahrscheinlich passieren sollen…)
Ich habe auch ein Problem bei der Ausführung dieses Updates (Web-Upgrade)
Nach der Ausführung dieser Befehle:
cd /var/discourse
git pull
./launcher rebuild app
läuft Discourse, aber der Zugriff auf das Admin-Panel (/admin) ist nicht möglich.
Ein Ubuntu-Update hat die Funktionsweise wiederhergestellt.
In der Ankündigung hieß es, dass Sie einen Neuaufbau über die Befehlszeile durchführen müssten. Ich bin mir nicht sicher, warum die Weboberfläche nicht wusste, dass dies durchgesetzt werden muss.
Seltsamerweise habe ich gerade versucht, diese Funktionalität in der Entwicklungsumgebung zu nutzen, und sie funktioniert bei mir nicht … Das Handlebars-Objekt hat nur create(), nicht compile(), obwohl ich vielleicht auf dem Holzweg bin … Ich habe dies hier zur Sprache gebracht: Adding a bespoke raw template
