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
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.
== 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
^
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).
== 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.
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 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
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.
Grazie mille per aver esaminato questo bug! 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. Sarebbe fantastico.
(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:
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.)