Hilfe beim Bereitstellen älterer Discourse-Versionen

Hier sollte ein Fehler vorliegen. Ich habe versucht, über den Tag v3.6.0.beta2 zu ziehen, und bin auf den folgenden Fehler gestoßen:

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

version unterstützt nur Branches, keine Tags!

Das Richtige wäre:

params:
  version: release/2025.11

Warum ich release/2025.11 ziehen wollte? Weil die aktuelle Produktionsumgebung diese nahe Version ist, und ich ein Upgrade durchführen möchte, aber Angst vor Problemen habe. Zudem erlaubt der Genehmigungsprozess mir nicht, direkt ein Upgrade durchzuführen. Ich muss zuerst den Upgrade-Prozess in der Testumgebung validieren (release/2025.11 => release/2026.1), bevor ich dies in der Produktionsumgebung tun kann. Obwohl dies etwas umständlich ist, ist es tatsächlich die beste Wahl, um den Prozess korrekt zu befolgen. Daher musste ich hier nach einer Möglichkeit suchen, einen bestimmten Branch oder Tag zu ziehen.

Entschuldigung für das viele Geschwätz. Glücklicherweise habe ich jetzt eine einigermaßen akzeptable Lösung gefunden. Vielen Dank an alle.

Ich werde die weiteren Auswirkungen dieser Änderung weiter aktualisieren:

Die Installation eines bestimmten Branches wurde erreicht, aber die Validierung des Upgrades von diesem Branch ist fehlgeschlagen. Da das neueste Update auf der Update-Seite nicht erkannt wird, kann das Update nicht auf der Seite bedient werden.

1 „Gefällt mir“

Fortsetzung des vorherigen Themas: Es wurde ein neues Problem festgestellt. Wenn das lokale Code-Repository veraltet ist, führt dies zu Kompilierungsfehlern im Frontend oder anderen Fehlern. Daher muss das lokale Code-Repository vor Beginn aller Änderungen auf die neueste Version aktualisiert werden.

# Wenn das lokale Code-Repository zuvor geändert wurde, speichern Sie die Änderungen zunächst
# git stash

# Auf den neuesten Stand bringen
git pull

# Die zwischengespeicherten Änderungen erneut anwenden oder die entsprechenden Konfigurationsdateien erneut bearbeiten
# git stash pop

Erst nachdem das lokale Repository auf die neueste Version aktualisiert wurde, kann die Installation gemäß den vorherigen Schritten erfolgreich den Build für den angegebenen Branch durchführen.

Das hier gemeinte lokale Code-Repository ist: https://github.com/discourse/discourse_docker.git

Das heißt das Repository nach der Standardinstallation.

Zum Schluss eine Zusammenfassung.

Unser Ziel ist: Installation einer bestimmten Version

  1. Lokales Code-Repository aktualisieren https://github.com/discourse/discourse_docker.git
# In das Stammverzeichnis des Projekts wechseln
cd /var/discourse
# Auf die neueste Version aktualisieren
git pull
  1. Die gewünschte Version festlegen

Ändern Sie templates/web.template.yml

params:
  version: release/2026.1
  1. Neu erstellen
./launcher rebuild app

Nach dieser Änderung besteht der nächste Schritt zum Aktualisieren und Upgraden darin, das lokale Code-Repository zu aktualisieren. Da wir jedoch lokale Änderungen vorgenommen haben, könnte der Update-Vorgang fehlschlagen. Daher ist es wahrscheinlich notwendig, lokale Änderungen vorübergehend zu speichern (git stash), gefolgt von einem git pull, um sicherzustellen, dass das lokale Repository auf dem neuesten Stand ist. Anschließend ändern Sie den zu aktualisierenden oder festzulegenden Branch und erstellen das System neu.

Ich denke, es wäre sehr ungewöhnlich, eine bestimmte Version anstelle eines Geschmacks/Streams/Tags wie „latest" oder „stable" zu konfigurieren. Ich bin mir eigentlich nicht mehr sicher, welche Tags mit diesem System üblich, verfügbar und nützlich sind.

Haben Sie sich Configure a supported tracking branch to get Discourse software updates bereits angesehen? Vielleicht hilft es dabei zu verstehen, welche Tags nützlich sind.

Ja, für normale Benutzer reicht die Standardversion latest aus. In meinem Fall muss ich jedoch untersuchen, wie man eine bestimmte Version verwendet. Ich kann meinem Chef schließlich nicht sagen: „Oh, leider unterstützt Discourse das Auschecken einer bestimmten Version derzeit nicht; wir können nur auf die neueste Version aktualisieren."

Dieser Beitrag ist sehr hilfreich, ich werde ihn mir genau ansehen. Danke.

Das hatte ich noch nicht gesehen – danke. Es sieht so aus, als sollten wir jetzt „latest/release/esr" verwenden. Ich sehe, dass meine eigene (alte) app.yml die Standardeinstellung übernimmt, weil sie auskommentiert ist:

  ## Welche Git-Revision sollte dieser Container verwenden? (Standard: tests-passed)
  #version: tests-passed

version unterstützt derzeit keine Tags. Um dies zu unterstützen, muss das Build-Skript angepasst werden. Die beste Praxis wäre eigentlich:

params:
  version: esr

Aktuell muss dies jedoch wie folgt geändert werden:

params:
  version: release/2026.1
1 „Gefällt mir“

Interessant. Selbst vor der neuen Versionsstrategie war beta schon seit geraumer Zeit ein Tag und kein Branch: Upcoming changes to the beta branch of Discourse

Es ist ich, ich bin auch verwirrt, aber der aktuelle Build-Code kann Tags tatsächlich nicht verwenden. Das sollte nicht so sein.

1 „Gefällt mir“

version: release/2026.1 sollte problemlos funktionieren. Wenn Sie die neuen überlappenden Unterstützungszeiträume für Versionen nutzen möchten, ist dies der korrekte Weg. (Sie müssen jedoch natürlich daran denken, das Update manuell durchzuführen, bevor 2026.1 sein Lebensende erreicht.)

version: esr sollte ebenfalls funktionieren. Das System ist so konzipiert, dass es Tags unterstützt. Es wird als git checkout $version implementiert.

Sie sollten diese Änderung nicht in web.template.yml vornehmen. Sie sollten sie in Ihrer sitespezifischen Datei containers/app.yml vornehmen.

4 „Gefällt mir“