Ciao da Gitpod! (installazione su Google Cloud e configurazione automatizzata dello sviluppo)

Ciao comunità Discourse! :wave:

Lavoro su gitpod.io, un IDE gratuito con un clic per GitHub. Attualmente usiamo Spectrum per la nostra comunità, ma abbiamo alcuni problemi e vorremmo mettere in piedi un’istanza di Discourse per provarla e, eventualmente, migrarci.

Se possibile, vorremmo utilizzare il nostro account Google Cloud per questo. Potreste indicarmi la strada giusta? Ad esempio, il nuovo Google Cloud Run è adatto per eseguire un’istanza di Discourse?

Inoltre, dato che la nostra missione è automatizzare completamente tutti gli ambienti di sviluppo (almeno per i progetti open source), vorrei contribuire con un’installazione completamente automatizzata di Discourse, permettendo ai contributori di avviare in un clic un ambiente Discourse pronto per la scrittura del codice online (invece di leggere lunghe liste di istruzioni di configurazione e installare/configurare manualmente molte dipendenze sul proprio dispositivo). Ho già iniziato a lavorare su questo basandomi sull’eccellente installazione automatizzata di Discourse per Janitor di @notriddle (ciao!).

Tuttavia, sto affrontando un problema: recentemente le istruzioni di installazione falliscono per una tabella “polls” mancante. Non sono ancora sicuro di come risolvere, ma continuerò a indagare. Ho solo pensato di menzionarlo qui.

Potrebbe esserlo, ma non è così semplice. Discourse non è un contenitore stateless, che è proprio ciò per cui è stato progettato Google Cloud Run; pertanto, avrai bisogno di una soluzione per aggiungere un volume persistente per i dati conservati da Discourse (upload, avatar, database).

Io utilizzerei una normale istanza di Google Compute e basta. Con uno script o strumenti di gestione dell’infrastruttura, dovresti essere in grado di automatizzare il deployment di nuove istanze di Discourse. Questa guida Install Discourse on Ubuntu or Debian for Development potrebbe esserti utile.

Quali istruzioni di configurazione stai utilizzando? Se manca la tabella polls, ciò suggerisce che non hai eseguito le migrazioni del plugin. Dovrebbero essere eseguite automaticamente in modalità sviluppo. In modalità test, devi aggiungere LOAD_PLUGINS=1 prima del comando rake db:migrate

Grazie per le vostre risposte @marianord e @david!

Sembra più ragionevole rispetto all’uso di Cloud Run, dato che estrarre tutti i dati di stato dai container di Discourse potrebbe richiedere del tempo. Grazie per avermi indicato la guida! Proverò a seguirla per configurare un’istanza Compute e farò qui un resoconto dei risultati.

Sto seguendo https://github.com/discourse/discourse/blob/master/docs/DEVELOPER-ADVANCED.md.

L’errore esatto che ho visto è stato:

== 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
                            ^

Mentre provavo a eseguire:

bundle exec rake db:create db:migrate &&
RAILS_ENV=test bundle exec rake db:create db:migrate

Ho anche provato ad aggiungere questa riga:

RAILS_ENV=development bundle exec rake db:create db:migrate

ma senza successo.

Grazie mille per il consiglio! Proverò e farò qui un resoconto anche di questo. (Scusa per aver fatto due domande in una! Spero che questo non renda la discussione troppo confusa.)

L’installazione per sviluppatori è molto più lenta ed è pensata per… lo sviluppo. Quindi dovresti seguire le istruzioni per l’installazione standard. È abbastanza semplice automatizzarla. Il mio servizio di installazione è ora completamente automatizzato (tranne le impostazioni DNS richieste da Mailgun, poiché non ho il controllo sul DNS del client).

La parte più difficile dell’installazione è la configurazione della posta.

Inoltre, l’installazione e la manutenzione sono cose diverse.

Grazie @pfaffman! Scusa per la confusione, ho mescolato due cose nel mio messaggio originale: 1) installare Discourse per la comunità Gitpod, e 2) automatizzare la configurazione di sviluppo per gli sviluppatori e i contributori di Discourse. Per il punto 2) sto seguendo con piacere la guida per gli sviluppatori, non per il punto 1). :sweat_smile:

@david Hmm, purtroppo, con:

bundle exec rake db:create db:migrate &&
RAILS_ENV=test LOAD_PLUGINS=1 bundle exec rake db:create db:migrate

Rimane un errore:

== Seed da /workspace/discourse/db/fixtures/990_settings.rb
L'hostname di Discourse: localhost non è un dominio valido per le email!

== Seed da /workspace/discourse/db/fixtures/990_topics.rb
rake aborted!
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERRORE: la relazione "polls" non esiste
LINE 8:  WHERE a.attrelid = '"polls"'::regclass
                            ^

Ho capito correttamente il tuo suggerimento? Avresti altre idee su come risolverlo? (Ho provato a eliminare le tabelle in precedenza, ma è fallito con un errore diverso che non ricordo. Sono comunque felice di riprovare.)

Inoltre, ho dimenticato di menzionare che le mie istruzioni di configurazione funzionavano fino a circa una settimana fa, quindi l’errore è apparso di recente dopo un rebase di Discourse. Penso che sia successo dopo la migrazione a Rails 6, forse? DEV: Upgrade Discourse to Rails 6 (#8083) · discourse/discourse@32b8a2c · GitHub

FYI, puoi riprodurre facilmente l’errore provando ad aprire il mio fork di Discourse su Gitpod: Dashboard. Vedrai che la mia configurazione automatizzata fallisce e otterrai un ambiente interattivo in cui è possibile provare vari comandi Discourse nel Terminale.

@sam Sembra che FIX: Rails 6 multisite migrations and plugin migrations · discourse/discourse@025d4ee · GitHub abbia rotto qualcosa.

Contrariamente al messaggio del commit, penso che le migrazioni dei plugin funzionassero prima di questo commit. Ora non funzionano più. Non importa se viene fornito LOAD_PLUGINS=1 o meno: le migrazioni dei plugin non vengono eseguite nel mio ambiente di sviluppo.

Credo che la causa sia questa:

--- a/lib/plugin/instance.rb
+++ b/lib/plugin/instance.rb
@@ -516,7 +516,7 @@ class Plugin::Instance
     Rake.add_rakelib(File.dirname(path) + "/lib/tasks")
 
     # Include automaticamente le migrazioni
-    migration_paths = Rails.configuration.paths["db/migrate"]
+    migration_paths = ActiveRecord::Migrator.migrations_paths
     migration_paths << File.dirname(path) + "/db/migrate"
 
     unless Discourse.skip_post_deployment_migrations?

Quindi si tratta di INSTALL-cloud.

Immagina che ci sia un contenitore Docker incluso con Discourse e che tu possa usarlo senza installare nulla.

Ho visto questo errore durante la migrazione del multisito; su dev/test db va tutto bene, oggi lo debuggerò con attenzione.

Per:

Questo dovrebbe far sì che gli ambienti di sviluppo si comportino correttamente quando si seguono le guide.

@kris.kotlarek, puoi dare un’occhiata a quel commit… perché il dump dello schema → caricamento ha smesso di funzionare in Rails 6 con i nostri plugin?

Certo, lo controllerò stasera.

Credo di aver individuato il problema per ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "polls" does not exist
Quando load_config viene valutato durante la creazione del database, sovrascrive migrations_paths

Quindi ecco cosa succede quando proviamo a eseguire db:create e db:migrate contemporaneamente:

Tuttavia, se li eseguiamo separatamente, i percorsi sono corretti:

Penso che abbiamo due opzioni:

  1. Modificare le guide e raccomandare di usare due comandi separatamente
  2. Applicare un monkey patch e usare ||=

Cosa ne pensi?

Va bene così?

RAILS_ENV=test bin/rake db:migrate
RAILS_ENV=test bin/rake db:schema:dump
dropdb discourse_test
createdb discourse_test
RAILS_ENV=test bin/rake db:schema:load
RAILS_ENV=test bin/rake db:migrate

Questo risolverebbe il problema originale relativo alla tabella polls mancante, menzionato qui: Hello from Gitpod! (installing on google cloud + automated dev setup) - #4 by jankeromnes
Lo stesso problema è stato menzionato in quell’argomento: Install Discourse on Ubuntu or Debian for Development - #320

Ho iniziato a eseguire il debug del codice per l’popolazione del DB di test, ma mi sono perso. Per qualche motivo, dopo il caricamento dello schema, quando si chiama db:migrate, Rails vuole ancora valutare le migrazioni e otteniamo un errore che la tabella esiste già. Finora non sono riuscito a trovare una ragione.

Capisco, allora per ora aggiustiamo le guide per l’op

Grazie mille per aver esaminato questo bug! :+1: Per ora utilizzerò le istruzioni aggiornate per aggirarlo.

Aha, interessante, grazie! Darò un’occhiata ai Dockerfile di sviluppo esistenti per vedere se possono essere semplicemente avviati con un clic da Gitpod. :smile: Sarebbe fantastico.

È interessante notare che, come suggerito in Install Discourse on Ubuntu or Debian for Development - #321, anche la separazione dei comandi db:create e db:migrate in due comandi distinti ha “funzionato”.

(Tuttavia, ora DISCOURSE_DEV_HOST=.gitpod.io bundle exec rails s -b 0.0.0.0 sembra andare in un ciclo di riavvio continuo con:

/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)

e il server web ha iniziato nuovamente a bloccare l’URL di anteprima di Gitpod:

Blocked host: 3000-a8a71720-4c30-466b-aea5-5344c97c4e94.ws-eu0.gitpod.io

)

Ho creato una pull request con una correzione per quel problema: FIX: Remove Versions from Active Record warm up by KrisKotlarek · Pull Request #8105 · discourse/discourse · GitHub

Potresti verificare se risolve il problema sulla tua macchina? (Sul mio locale funziona ora)

Ho appena modificato quella variabile d’ambiente aggiungendo una ‘s’ alla fine

https://review.discourse.org/t/dev-support-multiple-hosts-in-dev/5713

Ciao Jan, se hai tempo, sono curioso di sapere quali erano i problemi o cosa non ha funzionato come speravi con Spectrum?

Ho seguito un po’ Spectrum, leggendo di loro di tanto in tanto.

(Ho provato a inviarti un messaggio privato a riguardo, ma per qualche motivo, quando clicco sul tuo profilo, non c’è il pulsante per inviare un messaggio privato.)