Aide pour déployer d'anciennes versions de Discourse

Il devrait y avoir une erreur ici, j’ai essayé de tirer v3.6.0.beta2 par tag et j’ai rencontré l’erreur suivante :

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 '
  set -o errexit
  git fetch --tags --prune-tags --prune --force origin
  if [[ $(git symbolic-ref --short HEAD) == $version ]] ; then
      git pull
  else
      git -c advice.detachedHead=false checkout $version
  fi
'", "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 ne prend en charge que les branches, pas les tags !

Le correctif serait

params:
  version: release/2025.11

La raison pour laquelle je voulais tirer release/2025.11 est que l’environnement de production est actuellement sur une version proche de celle-ci, et je voulais passer à la suivante, mais j’avais peur que des problèmes surviennent. De plus, le processus d’examen ne m’autorise pas à effectuer la mise à niveau directement ; je dois d’abord valider le processus de mise à niveau sur l’environnement de test (release/2025.11 => release/2026.1) avant de pouvoir procéder sur l’environnement de production. Bien que ce soit un peu fastidieux, c’est le meilleur choix pour un processus correct. J’étais donc obligé de chercher ici comment tirer une branche ou un tag spécifique.

Désolé pour ce long bavardage. Heureusement, j’ai maintenant trouvé une solution acceptable. Merci à tous.

Je continue de mettre à jour les autres effets causés par cette modification :

L’installation de la branche spécifique a été réalisée, mais la mise à jour à partir de cette branche a échoué lors de la vérification. En effet, la dernière mise à jour n’est pas détectée sur la page de mise à jour, ce qui empêche l’opération de mise à jour sur la page.

1 « J'aime »

Revenons au sujet précédent, un nouveau problème a été identifié. Lorsque le dépôt local est obsolète, cela peut entraîner un échec de la compilation du frontend ou d’autres erreurs. Par conséquent, avant d’apporter toutes modifications, il est impératif de mettre à jour le dépôt local vers la dernière version.

# Si vous avez modifié le dépôt local précédemment, veuillez d'abord le mettre en réserve
# git stash

# Mettre à jour vers la dernière version
git pull

# Réappliquer les modifications mises en réserve, ou rééditer les fichiers de configuration correspondants
# git stash pop

Une fois le dépôt local mis à jour vers la dernière version, l’installation selon les étapes précédentes permettra de construire correctement la branche spécifiée.

Le dépôt local mentionné ici est : https://github.com/discourse/discourse_docker.git

C’est-à-dire le dépôt standard après installation.

Pour finir, faisons un résumé.

Notre besoin est : installer une version spécifique

  1. Mettre à jour le dépôt de code local https://github.com/discourse/discourse_docker.git
# Accéder au répertoire racine du projet
cd /var/discourse
# Mettre à jour vers la dernière version
git pull
  1. Modifier la version à spécifier

Modifier templates/web.template.yml

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

Après cette modification, les étapes suivantes pour mettre à jour consistent d’abord à mettre à jour le dépôt de code local. Cependant, comme nous avons modifié le code local, la mise à jour pourrait échouer. Il est donc très probable qu’il soit nécessaire de mettre en pause les modifications locales avec git stash, puis d’exécuter git pull pour s’assurer que le dépôt local est à jour. Ensuite, modifiez la branche que vous souhaitez mettre à jour ou spécifier, et enfin reconstruisez.

Je pense qu’il serait très inhabituel de configurer une version spécifique, plutôt qu’un flavour/stream/tag, comme latest ou stable. Je ne suis plus vraiment sûr de savoir quels tags sont normaux, disponibles et utiles avec ce système.

Avez-vous consulté Configure a supported tracking branch to get Discourse software updates ? Cela pourrait vous aider à comprendre quelles balises sont utiles.

Oui, pour un utilisateur standard, l’utilisation de la version par défaut latest suffit. Cependant, dans mon cas, je dois étudier comment utiliser une version spécifique. Je ne peux tout simplement pas dire au boss : « Oh, c’est regrettable, Discourse ne prend pas actuellement en charge la récupération d’une version spécifique ; nous ne pouvons mettre à jour que vers la dernière version. »

Ce post est très utile, je vais l’examiner attentivement. Merci.

Je n’avais pas vu cela - merci. Il semble que nous devions maintenant utiliser latest/release/esr. Je vois que mon propre fichier app.yml (ancien) récupère la valeur par défaut car il est commenté :

  ## Quelle révision Git ce conteneur doit-il utiliser ? (par défaut : tests-passed)
  #version: tests-passed

version ne prend pas actuellement en charge les balises ; pour les prendre en charge, il faut modifier le script de construction. La meilleure pratique était initialement :

params:
  version: esr

Mais actuellement, il faut le modifier en :

params:
  version: release/2026.1
1 « J'aime »

Intéressant. Même avant la nouvelle stratégie de versionnage, beta était une balise et non une branche depuis longtemps : Upcoming changes to the beta branch of Discourse

C’est moi aussi, je suis tout aussi perplexe, mais le code de construction actuel ne permet effectivement pas d’utiliser les balises. Cela ne devrait pas être le cas.

1 « J'aime »

version: release/2026.1 devrait fonctionner correctement. Si vous souhaitez tirer parti des nouveaux cycles de chevauchement de support des versions, c’est la méthode appropriée. (Mais bien sûr, vous devez vous rappeler de mettre à jour manuellement avant que 2026.1 n’atteigne sa fin de vie)

version: esr devrait également fonctionner. Le système est conçu pour prendre en charge les balises. Il est implémenté comme git checkout $version.

Vous ne devriez pas apporter cette modification dans web.template.yml. Vous devriez la faire dans votre fichier containers/app.yml spécifique à votre site.

4 « J'aime »