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.

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 Abschluss eine Zusammenfassung.

Unsere Anforderung lautet: Installation einer bestimmten Version

  1. Lokales Code-Repository aktualisieren https://github.com/discourse/discourse_docker.git
# Wechseln Sie in das Stammverzeichnis des Projekts
cd /var/discourse
# Auf die neueste Version aktualisieren
git pull
  1. Die gewünschte Version ändern

Bearbeiten Sie containers/app.yml und fügen Sie am Ende folgende Konfiguration hinzu:

params:
  version: release/2026.1 # Als Best Practice sollte hier: esr stehen
  1. Neu erstellen
./launcher rebuild app

Wenn version: esr verwendet wird, können die folgenden Schritte übersprungen werden.

Führen Sie zunächst git pull aus, um sicherzustellen, dass das lokale Code-Repository aktuell ist. Geben Sie dann den bereitzustellenden Branch an und erstellen Sie schließlich neu. Diese Anleitung gilt für das Szenario, bei dem von release/2026.1 auf release/2026.7 aktualisiert werden soll.

Wenn Sie lediglich eine bereits installierte release/2026.1 aktualisieren möchten, sollten Sie direkt im Verwaltungsbereich auf „Aktualisieren“ klicken. Dies gilt für Szenarien, in denen release/2026.1 Updates (insbesondere Sicherheitskorrekturen) erhält.

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

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.

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.

Etwas scheint hier nicht zu stimmen. Ich habe v3.5.0 beta3 ausgeführt, wobei die yml-Datei auf version: tests-passed gesetzt war.

Dann habe ich diese Versionsänderung bemerkt, und bevor ich neu aufgebaut habe, habe ich die yml-Datei auf version: esr geändert und dann einen Neuaufbau über die CLI durchgeführt.

Jetzt sehe ich in Discourse:

Installiert
2026.3.0-latest.1

Dies scheint das Tag „tests passed" anstelle des Tags „esr" zu verwenden. Ich habe überprüft, dass in der app.yml die Version als „esr" angezeigt wird. Warum wird also der neueste Build abgerufen?

Gibt es also im Wesentlichen keine Möglichkeit mehr, das neueste stabile / ESR-Release zu erhalten?

Können Sie die relevanten Zeilen der app.yml-Datei teilen? Ist version: definitiv unter dem Abschnitt params: eingerückt? Und haben Sie definitiv das YAML-Kommentarzeichen # vom Anfang der Zeile entfernt?

Nur zur Information: Wenn Sie wieder auf ESR zurückkehren möchten, müssen Sie entweder ein früheres Backup wiederherstellen oder bis zum nächsten ESR-Release im Juli warten. Ein Downgrade einer Discourse-Installation wird nicht unterstützt :cry:

Ja, mir ist bewusst, dass ich keine Downgrade durchführen kann. Ich füge einen Screenshot an, der die Einrückung zeigt.

Ist hier etwas falsch?

Ich glaube, version sollte eingerückt sein, da es Teil von params ist.

Ja, ich habe es anfangs direkt in containers/app.yml konfiguriert, aber aus unbekannten Gründen hatte dies keine Wirkung. Aus Verzweiflung habe ich daher direkt templates/web.template.yml geändert. Ich werde erneut versuchen, Änderungen in containers/app.yml vorzunehmen.

Außerdem, können Sie bitte prüfen, warum die Konfiguration version: esr nicht funktioniert? Ist dies ein Einzelfall bei mir oder tritt dies allgemein auf? Meine Netzwerkumgebung ist tatsächlich nicht optimal.

Konfiguration wie folgt:

params:
  version: v3.6.0.beta2

Fehlermeldung wie folgt:

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 ** bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen; es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
adc8ef45e9ae880827c9294dbbf73dfe9ab413a050c83fe3f4722c2911876ce2

Der Grund liegt darin, dass der Befehl git symbolic-ref --short HEAD nur den Branch-Namen zurückgeben kann.