J’ai reçu ce message lorsque j’ai essayé de mettre à niveau via l’interface utilisateur :
Après plusieurs git pulls et reconstructions, j’obtiens toujours le même message. Des astuces ?
Je me demande si je dois faire ceci :
Ceci est pour un ancien forum bien établi.
Cc @pacharanero
S’agissait-il d’une installation standard ? Pourrait-il s’agir de quelque chose comme une mise à niveau sur le mauvais serveur ? La reconstruction a-t-elle échoué et avez-vous redémarré l’ancien conteneur ? Je n’ai pas de meilleures hypothèses.
Vous devriez maintenir votre système d’exploitation à jour comme recommandé dans le sujet que vous avez lié, mais cela n’a rien à voir avec le problème que vous décrivez.
Cela m’a parfois intrigué lorsque la mise à jour de l’interface graphique ne semble pas être réinitialisée et qu’elle nous dirige vers une connexion SSH, même lorsque cela vient d’être fait.
C’était une installation standard, mais l’installation d’origine remonte à 2014, à l’époque où Discourse venait de sortir de la bêta publique.
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
Il existe une version plus récente de Docker, mais il est courant que la version d’Ubuntu soit un peu en retard par rapport à la dernière.
Le système d’exploitation est entièrement et régulièrement mis à jour.
Hmm. Il y a un délai après la mise à jour avant que Discourse ne vérifie si le conteneur a été reconstruit, bien que je n’aie jamais su que cela affectait docker-manager.
Vous pourriez essayer ceci :
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
Mais cela fait assez longtemps maintenant, donc je ne pense pas que ce soit votre problème. Cela ne peut pas faire de mal, cependant.
Je ne me souviens pas de la version minimale de docker prise en charge, mais je ne pense pas que ce soit non plus le problème, du moins si vous n’êtes pas sur Ubuntu 16.04.
Y a-t-il un moyen que cela concerne la branche sur laquelle nous exécutons ?
Dans containers/app.yml, nous sélectionnons explicitement tests-passed
Mais bien sûr, c’est ce qui s’exécute À L’INTÉRIEUR du conteneur. Est-ce que cela aurait de l’importance quelle est la branche par défaut à l’extérieur du conteneur ?
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
Autrefois, master était la valeur par défaut sur GitHub. Maintenant, c’est main.
D’accord. Je suppose que vous pourriez essayer
cd /var/discourse
git checkout main
Mais je ne pensais pas que vous deviez le faire explicitement.
Et si
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
Ceci est lié à discourse_docker, bien sûr :
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
La branche a été basculée en août 2021 et a 49 commits de retard sur main au moment de la rédaction : GitHub - discourse/discourse_docker at master
Alors vous voulez absolument passer à la branche main ?
Cependant, je suis d’accord avec @pfaffman, je ne l’ai jamais fait explicitement, donc il doit y avoir eu un script qui l’a fait. Peut-être que cela se produira lors de la prochaine reconstruction ?
renvoie
user@inside-container-app:/var/www/discourse# git status
Rafraîchissement de l'index : 100 % (30949/30949), terminé.
Sur la branche tests-passed
Votre branche est à jour avec 'origin/tests-passed'.
Il semble que vous soyez à jour. Et vous recevez toujours la page Mises à niveau désactivées ?
Oui. J’ai regardé sur un autre Discourse que j’administre, qui date un peu, et qui est également sur master, et il présente également la même page « Mises à niveau désactivées ».
Cela dit, un autre Discourse que j’ai mis en place à la mi-2022 est également sur master et présente l’écran de mise à jour normalement !
Si nous pouvons obtenir une confirmation que le changement de branche de discourse_docker pour suivre main résoudra le problème, alors je suis prêt à essayer. Peut-être sur un site que j’utilise uniquement.
Cela coïnciderait à peu près avec le moment où j’ai commencé à avoir des comportements étranges sur certains Discourses au moment des mises à jour. (Pour cette raison, j’ai fini par les mettre tous à jour via SSH à chaque fois, en utilisant Ansible).
C’est à peu près ce que je fais toujours aussi, bien que de plus en plus, j’augmente le script de mise à niveau Ansible avec https://www.pfaffmanager.com/.
Ok, j’ai basculé le suivi sur main sur un Discourse que j’utilise uniquement comme bloc-notes et journal personnel, etc.
Avant la bascule, je suivais master et la page de mise à niveau de l’administrateur était effectivement désactivée.
En passant au suivi de main et en reconstruisant, je peux confirmer que l’interface utilisateur de mise à niveau de l’administrateur fonctionne à nouveau normalement.
Hmmm. Je me demande si cela signifie que toutes ces anciennes installations doivent changer de branche. @Falco, vous voudrez peut-être voir cela.
Le lanceur change automatiquement la branche de master à main. Il semble que quelque chose bloquait le changement automatique, comme des modifications en attente dans le stash.
Quelle est la probabilité que cela se produise sur autant d’instances ?
Et qu’est-ce que ces modifications de dépôt ?
De combien parlons-nous ? Il existe des milliers de forums Discourse, et je ne vois pas des dizaines de rapports sur ce problème. Du moins, pas encore 
Si quelqu’un a un serveur qui reproduit actuellement ce bug et peut le maintenir ainsi pendant encore une journée, veuillez répondre ici afin que nous puissions enquêter davantage.
Hmmmm. Cela pourrait avoir un rapport avec cela sur notre instance @nathank
J’ai quelques fichiers opérationnels (qui n’ont rien à voir avec le code de Discourse) dans le même répertoire que le dépôt Git de Discourse. Si ./launcher tentait de changer de branche, Git échouerait, me forçant à stasher ces modifications (ou à les commiter).
Merci @Falco Je vais mener une enquête plus approfondie. Il se peut que les seules instances de Discourse qui seraient affectées soient celles dans lesquelles Git échoue pour une raison quelconque lors de la tentative de changement de branche.
Mise à jour : Je pense que ce problème avec certains fichiers non suivis *a pu être le problème.
J’ai supprimé les fichiers et je me suis assuré que la commande git checkout main réussissait.
Ensuite, j’ai exécuté ./launcher rebuild app et cela semble avoir fonctionné.
D’après ce que je comprends, et conformément à ce que @Falco indique ci-dessus, je ne pense pas qu’il soit réellement nécessaire de suivre main dans le dépôt Discourse. Lorsque vous exécutez ./launcher rebuild app, le script lui-même vérifie la bonne branche.
J’ai eu quelques anciens Discourses qui affichaient toujours la page Mises à niveau désactivées malgré avoir vérifié que
git checkout main
git pull
git checkout master
fonctionnaient sans erreurs.
Et pour ceux-ci, j’ai simplement laissé ces instances suivre main et ./launcher rebuild app et tout allait bien.