Ich arbeite bei gitpod.io, einer kostenlosen One-Click-IDE für GitHub. Wir nutzen derzeit Spectrum für unsere Community, haben aber einige Probleme damit und würden gerne eine Discourse-Instanz zum Ausprobieren und potenziellen Umstieg einrichten.
Wenn möglich, möchten wir dafür unser Google Cloud-Konto verwenden. Könntet ihr mich bitte in die richtige Richtung weisen? Ist zum Beispiel der neue Google Cloud Run eine gute Wahl, um eine Discourse-Instanz zu betreiben?
Da es unsere Mission ist, alle Entwicklerumgebungen vollständig zu automatisieren (zumindest für Open-Source-Projekte), möchte ich eine vollständig automatisierte Einrichtung für Discourse beisteuern. Damit können Contributors mit einem Klick eine sofort einsatzbereite Discourse-Umgebung online starten (anstatt lange Listen mit Einrichtungshinweisen zu lesen und manuell viele Abhängigkeiten auf ihrem aktuellen Gerät zu installieren und zu konfigurieren). Ich habe bereits mit der Arbeit daran begonnen, basierend auf @notriddles (Hallo!) hervorragender automatisierten Discourse-Einrichtung für Janitor.
Ich stoße jedoch aktuell auf ein Problem, da die Einrichtungshinweise seit Kurzem an einer fehlenden „polls“-Tabelle scheitern. Ich bin mir noch nicht sicher, wie ich das beheben soll, werde aber weiter recherchieren. Ich wollte es nur hier kurz erwähnen.
Das könnte es sein, aber es ist nicht so einfach. Discourse ist kein zustandsloser Container, wofür Google Cloud Run ausgelegt ist. Daher benötigen Sie eine Möglichkeit, ein Persistent Volume für die in Discourse gespeicherten Daten (Uploads, Avatare, Datenbank) hinzuzufügen.
Ich würde stattdessen eine normale Google Compute-Instanz verwenden. Mit Hilfe eines Skripts oder von Infrastruktur-Management-Tools sollten Sie in der Lage sein, die Bereitstellung neuer Discourse-Instanzen zu automatisieren. Diese Anleitung Install Discourse on Ubuntu or Debian for Development könnte Ihnen ebenfalls helfen.
Welche Einrichtungshinweise verwendest du? Wenn die „polls“-Tabelle fehlt, deutet das darauf hin, dass du die Plugin-Migrationen nicht ausgeführt hast. Diese sollten im Entwicklungsmodus automatisch ausgeführt werden. Im Testmodus musst du LOAD_PLUGINS=1 vor dem Befehl rake db:migrate hinzufügen.
Das klingt vernünftiger als die Nutzung von Cloud Run, da das Extrahieren des gesamten Zustands aus Discourse-Containern einige Zeit in Anspruch nehmen könnte. Danke für den Hinweis auf den Leitfaden! Ich werde versuchen, ihn zu befolgen, um eine Compute-Instanz einzurichten, und hier mit meinen Erkenntnissen zurückmelden.
Die genaue Fehlermeldung, die ich gesehen habe, war:
== Seed from /workspace/discourse/db/fixtures/990_settings.rb
Discourse hostname: localhost is not a valid domain for emails!
== Seed from /workspace/discourse/db/fixtures/990_topics.rb
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist
LINE 8: WHERE a.attrelid = '"polls"'::regclass
^
Vielen Dank für den Tipp! Ich werde das ausprobieren und mich ebenfalls hier zurückmelden. (Entschuldige, dass ich zwei Fragen in einem Beitrag gestellt habe! Hoffentlich wird die Diskussion dadurch nicht zu verwirrend.)
Die Entwickler-Installation ist deutlich langsamer und für …Entwicklung konzipiert. Du solltest daher die Standard-Installationsanweisungen befolgen. Die Automatisierung ist recht einfach. Mein Installationsdienst ist nun vollständig automatisiert (außer den für Mailgun erforderlichen DNS-Einstellungen, da ich keine Kontrolle über die Client-DNS habe).
Der schwierigste Teil der Installation ist die Mail-Konfiguration.
Außerdem unterscheiden sich Installation und Wartung.
Danke @pfaffman! Entschuldige bitte die Verwirrung. Ich habe in meiner ursprünglichen Nachricht zwei Dinge durcheinandergebracht: 1) die Installation von Discourse für die Gitpod-Community und 2) die Automatisierung der Entwicklerumgebung für Discourse-Entwickler und -Mitwirkende. Zum Glück folge ich für Punkt 2 dem Entwicklerleitfaden, nicht für Punkt 1.
== Seed from /workspace/discourse/db/fixtures/990_settings.rb
Discourse hostname: localhost is not a valid domain for emails!
== Seed from /workspace/discourse/db/fixtures/990_topics.rb
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist
LINE 8: WHERE a.attrelid = '"polls"'::regclass
^
Habe ich deinen Vorschlag richtig verstanden? Hast du noch andere Ideen, wie man das beheben könnte? (Ich habe versucht, die Tabellen vorher zu löschen, aber das schlug mit einem anderen Fehler fehl, an den ich mich nicht mehr erinnere. Ich bin gerne bereit, es erneut zu versuchen.)
Zur Info: Du kannst den Fehler leicht reproduzieren, indem du versuchst, meinen Discourse-Fork in Gitpod zu öffnen: Dashboard . Du wirst sehen, dass meine automatisierte Einrichtung fehlschlägt, und du erhältst eine interaktive Umgebung, in der du verschiedene Discourse-Befehle im Terminal ausprobieren kannst.
Entgegen der Commit-Nachricht waren Plugin-Migrationen vor diesem Commit meiner Meinung nach funktionsfähig. Das ist jetzt nicht mehr der Fall. Es spielt keine Rolle, ob LOAD_PLUGINS=1 angegeben wird oder nicht – Plugin-Migrationen werden in meiner Entwicklungsumgebung nicht ausgeführt.
Stell dir vor, es gäbe einen Docker-Container, der mit Discourse ausgeliefert wird und den du einfach nutzen kannst, ohne etwas installieren zu müssen.
Ich habe diesen Fehler bei der Multisite-Migration gesehen. Auf der Dev/Test-Datenbank funktioniert es einwandfrei. Ich werde ihn heute sorgfältig debuggen.
Ich glaube, ich habe das Problem bei ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist gefunden.
Wenn load_config bei der Datenbankerstellung ausgewertet wird, überschreibt es migrations_paths.
Ich habe begonnen, den Code zum Befüllen der Test-Datenbank zu debuggen, bin aber gescheitert. Aus irgendeinem Grund möchte Rails, nachdem das Schema geladen wurde, beim Aufruf von db:migrate weiterhin Migrationen ausführen, und wir erhalten einen Fehler, dass die Tabelle bereits existiert. Bisher konnte ich keinen Grund dafür finden.
Vielen Dank, dass du dir diesen Fehler angesehen hast! Ich werde vorerst die aktualisierten Anweisungen nutzen, um ihn zu umgehen.
Aha, interessant, danke! Ich werde mir die bestehenden Dockerfiles für die Entwicklung ansehen, um zu prüfen, ob sie sich mit einem Klick über Gitpod starten lassen. Das wäre cool.
(Aber jetzt scheint DISCOURSE_DEV_HOST=.gitpod.io bundle exec rails s -b 0.0.0.0 in einer Endlosschleife zu abstürzen mit:
/workspace/.rvm/gems/activesupport-6.0.0/lib/active_support/dependencies.rb:551:in `load_missing_constant': Unable to autoload constant Version, expected /workspace/discourse/lib/version.rb to define it (LoadError)
und der Webserver blockiert meine Gitpod-Vorschau-URL erneut:
Hallo Jan, wenn du Zeit hast, würde ich gerne wissen, welche Probleme es mit Spectrum gab bzw. was nicht so lief, wie du es dir erhofft hattest?
Ich habe Spectrum ein wenig verfolgt und von Zeit zu Zeit darüber gelesen.
(Ich habe versucht, dir eine PN zu diesem Thema zu senden, aber aus irgendeinem Grund gibt es beim Klick auf dein Profil keine Schaltfläche für private Nachrichten.)
Ich werde vorerst die aktualisierten Anweisungen nutzen, um ihn zu umgehen.
Das wäre cool.