Discourse_docker: Launcher-Bootstrap schlägt fehl (Workaround enthalten)

Unterstützung
1

Das Bootstrapping eines frischen Container-Images schlägt fehl. Vor einigen Tagen hat es funktioniert, „nichts hat sich geändert“, heute schlägt es fehl. Log:

[0:02:27] Noch in Bearbeitung:
[0:02:27]   v8
________ Ausführung von 'vpython third_party/depot_tools/update_depot_tools_toggle.py
--disable' in
'/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor/depot_tools/.cipd_bin/.cipd/pkgs/0/fI6WggdkRyN1r91MnTeApc2_gyTtXfYpueHZVLcaF8gC/vpython:
Optionen konnten nicht aufgelöst werden: Fehler beim Auflösen des Python-Skripts: stat
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor/third_party/depot_tools/update_depot_tools_toggle.py:
Datei oder Verzeichnis nicht gefunden
Fehler: Der Befehl 'vpython third_party/depot_tools/update_depot_tools_toggle.py
--disable' gab in
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor
einen Nicht-Null-Exit-Status 1 zurück.

...

** BOOTSTRAPPING FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen; es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.

Bei der Untersuchung: Für libv8 wurde bereits ein ähnliches Problem auf GitHub gemeldet, das mit einer Versionsänderung im Ruby-Build-System zusammenhängt. Während des Bootstrappings wird ein Upgrade des Builders durchgeführt. Ich denke, das Problem scheint mit der Version 2.2.15 von Bundler (gestern veröffentlicht) zusammenzuhängen. Um ehrlich zu sein: Ich bin kein Ruby-Experte, also könnte das eigentliche Problem etwas anders liegen.

Dennoch hat der folgende Workaround bei mir funktioniert: Ändern Sie Zeile 148 in templates/web.template.yml von
- gem update bundler
in
- gem install bundler -v 2.2.14

Beste Grüße,

Michael

2

War das beim Versuch, auf dem stabilen Zweig zu bauen?

3

Guter Punkt! Master-Zweig von discourse_docker, Parameter: version: stable in app.yml

4

Es sei denn, Sie haben einen Grund, stable auszuführen und sind bereit, einige Dinge (wie dieses Problem) besonders im Auge zu behalten, sind Sie mit tests-passed besser beraten. Diese Version wird viel gründlicher getestet und ist diejenige, die Discourse für ihr Hosting verwendet.

5

Das ist mit Sicherheit debuggen wert. Wenn Bundler gerade einen Fehler eingeführt hat, wollen wir schnell eine Workaround-Lösung bereitstellen.

@kris.kotlarek, kannst du das Problem auf Digital Ocean reproduzieren?

8

Hier spielen mehrere Probleme eine Rolle. Derzeit ist die reibungsloseste Lösung, die Gemfile-Version in der stabilen Version hochzupusten. Weitere Details finden Sie in der Commit-Nachricht:

@m.abi bitte versuche erneut, neu zu bauen – es sollte jetzt funktionieren.

9

Ich gehe davon aus, dass eine Installation auf stable mehr Stabilität bietet – idealerweise Sicherheitsupdates und sonst nichts. Das ist zumindest unsere Interpretation des stable-Zweigs. Und man muss sich bei stable nicht mehr um etwas kümmern, nur weil es häufiger kaputtgehen könnte als die bleeding edge-Version.

10

Nun, wie dieser Fall zeigt, ist es etwas anders, als man vielleicht erwartet. Sie machen einen guten Job darin, Dinge schnell zu beheben (wie hier), aber sie hosten ‘stable’ (meistens?) nicht selbst, sodass es weniger gut getestet ist als ‘tests-passed’. Daher halte ich ‘tests-passed’ – außer direkt nach einer neuen ‘stable’-Veröffentlichung – für eine etwas “sicherere” Wahl. Nicht alle sind derselben Meinung.

11

@david Der Build funktioniert! Danke!