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.

1 Mi Piace

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, ecco un riepilogo.

La nostra esigenza è: installare una versione specifica

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

Modifica templates/web.template.yml

params:
  version: release/2026.1
  1. Ricompila
./launcher rebuild app

Dopo questa modifica, i passaggi successivi per aggiornare e migliorare richiedono prima di aggiornare il repository locale del codice. Tuttavia, poiché abbiamo modificato il codice locale, l’aggiornamento potrebbe fallire. Pertanto, è molto probabile che sia necessario salvare temporaneamente le modifiche locali con git stash, quindi eseguire git pull per assicurarsi che il repository locale sia aggiornato. Successivamente, modifica il ramo che desideri aggiornare o specificare e infine ricompila.

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
1 Mi Piace

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ì.

1 Mi Piace

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.

4 Mi Piace