Aiuto per la distribuzione di versioni più vecchie di Discourse

Qui dovrebbe esserci un errore, ho provato a estrarre la tag v3.6.0.beta2 e ho ricevuto l’errore seguente:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  git fetch --tags --prune-tags --prune --force origin
  if [[ $(git symbolic-ref --short HEAD) == v3.6.0.beta2 ]] ; then
      git pull
  else
      git -c advice.detachedHead=false checkout v3.6.0.beta2
  fi
' failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `Pups::ExecCommand#spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"code", "cmd"=>["sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\\n  set -o errexit\\n  git fetch --tags --prune-tags --prune --force origin\\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\\n      git pull\\n  else\\n      git -c advice.detachedHead=false checkout $version\\n  fi\\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/uploads,/shared/backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp", "[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete"]}
bootstrap failed with exit code 128
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
adc8ef45e9ae880827c9294dbbf73dfe9ab413a050c83fe3f4722c2911876ce2

version supporta solo i branch, non i tag!

Quello corretto è

params:
  version: release/2025.11

Riguardo al perché volessi estrarre release/2025.11, è perché l’ambiente di produzione attuale è una versione vicina a questa, e volevo effettuare l’aggiornamento, ma temevo problemi, e il processo di revisione non mi permette di eseguire direttamente l’aggiornamento; devo prima verificare il processo di aggiornamento nell’ambiente di test (da release/2025.11 a release/2026.1) e solo dopo procedere in produzione. Anche se questo è un po’ tedioso, è la scelta migliore per un processo corretto. Perciò, ho dovuto cercare qui un modo per estrarre un branch o un tag specifico.

Scusate per tutte queste chiacchiere inutili. Fortunatamente, ora ho trovato una soluzione abbastanza accettabile. Grazie a tutti.

Continuo ad aggiornare gli altri effetti causati da questa modifica:

L’installazione di un ramo specifico è riuscita, ma il tentativo di eseguire l’aggiornamento da quel ramo è fallito. Poiché l’aggiornamento più recente non viene rilevato nella pagina di aggiornamento, non è possibile eseguire l’aggiornamento tramite la pagina.

Riprendiamo il discorso precedente: è stato individuato un nuovo problema. Se il repository locale è obsoleto, ciò può causare errori nella compilazione del frontend o altri errori. Pertanto, prima di apportare qualsiasi modifica, è necessario aggiornare il repository locale all’ultima versione.

# Se hai apportato modifiche al repository locale, archiviale prima
# git stash

# Aggiorna all'ultima versione
git pull

# Riapplica le modifiche archiviate o modifica di nuovo i file di configurazione corrispondenti
# git stash pop

Solo dopo aver aggiornato il repository locale all’ultima versione sarà possibile completare con successo l’installazione dei passaggi precedenti per la compilazione del ramo specificato.

Per “repository locale” si intende: https://github.com/discourse/discourse_docker.git

ovvero il repository standard dopo l’installazione.

Infine, un riepilogo.

Il nostro obiettivo è: installare una versione specifica

  1. Aggiornare il repository locale del codice https://github.com/discourse/discourse_docker.git
# Entrare nella directory principale del progetto
cd /var/discourse
# Aggiornare all'ultima versione
git pull
  1. Modificare la versione da specificare

Modificare containers/app.yml aggiungendo la seguente configurazione alla fine:

params:
  version: release/2026.1 # La migliore pratica prevede di scrivere: esr
  1. Ricostruire
./launcher rebuild app

Se si utilizza version: esr, non è necessario leggere il resto.

Innanzitutto eseguire git pull per garantire che il repository locale sia aggiornato. Quindi specificare il branch da distribuire e infine ricostruire. Questa spiegazione è适用于 lo scenario in cui si desidera aggiornare da release/2026.1 a release/2026.7.

Se si desidera semplicemente aggiornare una versione già installata, come release/2026.1, è sufficiente fare clic su “Aggiorna” nel pannello di amministrazione. Questo vale per gli scenari in cui release/2026.1 ha aggiornamenti disponibili (in particolare correzioni di vulnerabilità).

Penso che sarebbe molto insolito configurare una versione specifica, piuttosto che un gusto/stream/tag, come latest o stable. In realtà non sono più sicuro di quali tag siano normali, disponibili e utili con questo sistema.

Hai dato un’occhiata a Configure a supported tracking branch to get Discourse software updates? Forse può aiutare a capire quali tag sono utili.

Sì, per gli utenti normali l’utilizzo della versione predefinita latest è sufficiente. Tuttavia, nel mio caso, è necessario studiare come utilizzare una versione specifica. Non posso dire al mio boss: “Oh, mi dispiace, Discourse non supporta al momento il checkout di versioni specifiche; possiamo aggiornare solo all’ultima versione.”

Questo post è molto utile, lo esaminerò attentamente. Grazie.

Non l’avevo visto, grazie. Sembra che dovremmo ora utilizzare latest/release/esr. Vedo che il mio vecchio file app.yml rileva il valore predefinito perché è commentato:

  ## Quale revisione Git dovrebbe utilizzare questo container? (default: tests-passed)
  #version: tests-passed

version attualmente non supporta i tag; per abilitarli, è necessario modificare gli script di build. La migliore pratica sarebbe:

params:
  version: esr

ma al momento è necessario modificarlo in:

params:
  version: release/2026.1

Interessante. Anche prima della nuova strategia di versionamento, beta era un tag invece di un branch da quite a while: Upcoming changes to the beta branch of Discourse

Sono io, sono anch’io confuso, ma il codice di build attuale non può effettivamente utilizzare i tag. Non dovrebbe essere così.

version: release/2026.1 dovrebbe funzionare correttamente. Se desideri sfruttare i nuovi periodi di sovrapposizione di supporto per le versioni, questo è il modo corretto per farlo. (ma ovviamente, devi ricordarti di aggiornare manualmente prima che 2026.1 raggiunga la fine del suo ciclo di vita)

version: esr dovrebbe funzionare anch’esso. Il sistema è progettato per supportare i tag. È implementato come git checkout $version.

Non dovresti apportare questa modifica in web.template.yml. Dovresti farlo nel tuo file specifico per il sito containers/app.yml.

Qualcosa non sembra corretto qui. Stavo eseguendo la versione v3.5.0 beta3 con il file yml impostato su version: tests-passed.

Poi ho notato questo cambiamento di versionamento, quindi prima di ricostruire ho modificato il file yml impostandolo su version: esr e ho eseguito una ricostruzione da riga di comando.

Ora in Discorso vedo:

Installato
2026.3.0-latest.1

Sembra che stia utilizzando il tag tests-passed invece del tag esr. Ho verificato che app.yml mostri la versione come esr, quindi perché sta recuperando l’ultima build?

Quindi, essenzialmente, non c’è più modo di ottenere l’ultima build stabile / ESR?

Puoi condividere le righe pertinenti del file app.yml? version: è sicuramente indentato sotto la sezione params:? E hai sicuramente rimosso il carattere di commento YAML # dall’inizio della riga?

Solo per tua informazione, se desideri tornare alla versione ESR, dovrai ripristinare un backup precedente o attendere il prossimo rilascio ESR a luglio. Il downgrade di un’installazione di Discourse non è supportato :cry:

Sì, sono consapevole che non posso eseguire un downgrade. Allego uno screenshot che mostra l’indentazione.

Hai notato qualcosa di sbagliato qui?

Credo che version debba essere indentato perché fa parte di params.

Sì, all’inizio ho configurato direttamente in containers/app.yml, ma non so perché non abbia funzionato. Per necessità ho modificato direttamente templates/web.template.yml. Riproverò a modificare in containers/app.yml.

Inoltre, potresti verificare perché la configurazione version: esr non ha effetto? È un caso isolato dal mio lato o è una situazione comune? Il mio ambiente di rete è effettivamente poco affidabile.

La configurazione è la seguente:

params:
  version: v3.6.0.beta2

L’errore è il seguente:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && sudo -H -E -u discourse bash -c '
  set -o errexit
  git fetch --tags --prune-tags --prune --force origin
  if [[ $(git symbolic-ref --short HEAD) == v3.6.0.beta2 ]] ; then
      git pull
  else
      git -c advice.detachedHead=false checkout v3.6.0.beta2
  fi
' failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'
exec failed with the params {"cd" => "$home", "hook" => "code", "cmd" => ["sudo -H -E -u discourse git clean -f", "sudo -H -E -u discourse bash -c '\n  set -o errexit\n  git fetch --tags --prune-tags --prune --force origin\n  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then\n      git pull\n  else\n      git -c advice.detachedHead=false checkout $version\n  fi\n'", "sudo -H -E -u discourse git config user.discourse-version $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/{uploads,backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp", "[ ! -d public/plugins ] || find public/plugins/ -maxdepth 1 -xtype l -delete"]}
bootstrap failed with exit code 128
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
adc8ef45e9ae880827c9294dbbf73dfe9ab413a050c83fe3f4722c2911876ce2

La causa fondamentale è che il comando git symbolic-ref --short HEAD può restituire solo il nome del ramo.