Ho un sistema in esecuzione da molto tempo, non ho mai avuto problemi prima. Aggiorno sempre con una ricostruzione completa, senza mai usare l’aggiornamento integrato.
Recentemente ho eseguito un apt-get upgrade, ho aggiornato Docker alla versione 19.03.5 e ho provato a ricostruire, ma ora è rotto. Il sistema è Ubuntu 16.04.6.
@j.jaffeux Dovrebbe essere retroportato Discourse.redis su stable e beta? Immagino che sarebbe più semplice rispetto all’aggiunta di codice per la compatibilità all’indietro in più plugin.
Sono quasi certo che le ultime modifiche abbiano rotto docker_manager, poiché viene aggiornato prima di Discourse e quindi non riesce a trovare Discourse.redis.
Breve riassunto: tests-passed ha funzionato, ho avuto un’interruzione di servizio di 1 giorno
Versione più dettagliata: Credo che questo sia uno dei software open source di qualità più elevata scritti oggi su Internet, con un modello di business solido e un ottimo team. Come mai il meccanismo di aggiornamento è così rotto?
La funzione di aggiornamento nell’app mi ha causato così tante interruzioni di servizio che ho deciso di non usarla affatto, optando invece per un rebuild ogni volta.
Ma come puoi vedere da questa discussione, nelle ultime due occasioni il rebuild ha prodotto un’app completamente rotta, qualcosa che non potevo assolutamente risolvere da solo, se non ricorrendo a “tests-passed” come consigliato qui.
Perché il meccanismo di aggiornamento è così rotto in un software così ben scritto? Perché ho siti WordPress attivi da oltre 5 anni che funzionano senza problemi con il loro meccanismo di aggiornamento integrato?
Qual è lo scopo delle release in Discourse se non esiste letteralmente alcun modo per utilizzarle? Un rebuild è sempre eseguito da un branch git, mentre le release non hanno nulla a che fare con git.
Per me una release dovrebbe essere o un tag git o un file zip. Perché non posso semplicemente usare rebuild con la versione 2.3.x, come si può fare con qualsiasi gestore di pacchetti moderno oggi?
Come si è scoperto, tests-passed è la versione che discourse.org distribuisce sui propri server ed è più testata e affidabile rispetto a stable. Se rimani su tests-passed, avrai meno problemi. Se desideri eseguire stable, devi sapere che richiederà più lavoro rispetto all’esecuzione di tests-passed, ad esempio l’utilizzo di un server di staging per testare gli aggiornamenti prima di applicarli in produzione.
Voglio solo qualcosa di stabile e affidabile, basato su
tests-passed è ciò che discourse.org distribuisce sui propri server ed è più testato e affidabile di stable
Mi atterrò a questo. Due cose sono ancora molto strane:
Perché si chiama test-passed e non stable, se è davvero stabile? “stable” potrebbe essere rinominato in qualcosa come “legacy”.
Il sistema di rilascio non ha ancora senso. Se stiamo costruendo da un ramo Git, qual è lo scopo di fare rilasci? Mi piacerebbe poter rimanere su 2.3.x finché 2.4.x non si stabilizza, ad esempio, e credo che con il modello di Discourse questo non sia assolutamente possibile.
Con tutto il rispetto, ma non sono d’accordo. Stable è molto affidabile e, beh, stabile. Rubygems ha aggiornato una dipendenza che ha rotto siatests-passedsiastable, e risolvere il problema è stato semplicemente una questione di backport di una correzione.
Comunque, questo avrebbe potuto essere evitato fissando una versione specifica di Rubygems nel comando gem update. gem update --system 3.0.6 sarebbe stato sicuro.
Il fatto che stable sia stato rotto più a lungo di tests-passed è solo una coincidenza e, per quanto mi ricordi, una prima volta.
Lo stiamo facendo (mantenere stable come predefinito) da oltre sei anni con centinaia di istanze di Discourse senza problemi significativi.
Proprio in questa discussione ci sono diversi casi in cui la versione stable è stata ricostruita in uno stato rotto; non è certo la prima volta. Se le istanze commerciali di discourse.org sono considerate passate ai test, allora mi atterrò a quelle.
Lo facciamo da oltre sei anni (mantenendo la stable come predefinita) con centinaia di istanze Discourse, senza problemi significativi.
Mantenere la stable e rimanere sulla 2.3.x sono cose molto diverse. Ad esempio, la stable non ti permette di restare sulla 2.3.x finché la 2.4.x non matura a sufficienza. In un ambiente di produzione, preferisco aggiornare solo quando escono versioni x.x.3 o x.x.4. Oggi, a quanto pare, questo non è possibile.
So che è vero, ma tu non sei un amministratore Discourse medio. Mi hai salvato molte volte e, in linea di principio, leggo tutto ciò che dici due volte per assicurarmi di ricordarlo, ma ritengo comunque che per la maggior parte delle persone normali sia più sicuro attenersi a tests-passed.
Puoi utilizzare un ID di commit git invece di un tag.
Ma anche se lo facessi, non mi salverebbe in una situazione in cui la versione stabile è rotta, vero? In entrambi i casi il problema era un backport mancante, e questo mancherebbe ugualmente in qualsiasi ID di commit git, credo.
Quindi non esiste una vera “release” di Discourse dove puoi scaricare un file zip alla maniera di WordPress o utilizzare un gestore di pacchetti come yarn/pip/gem, semplicemente perché Discourse non viene rilasciato, ma viene “ricostruito”, utilizzando sempre le versioni live dei pacchetti esterni.
Mi hai salvato molte volte e, in linea di principio, leggo tutto ciò che dici due volte per assicurarmi di ricordarlo, ma ritengo comunque che per la maggior parte delle persone normali sia più sicuro attenersi a tests-passed.