J’ai une mise à jour qui échoue et j’essaie de déterminer quel message d’erreur en est la cause. Toutes les mises à jour que j’ai effectuées au cours des un ou deux dernières années ont échoué et ont nécessité beaucoup de manipulations pour les terminer.
J’ai remarqué ces messages de dépendances pair non satisfaites lors de chaque mise à jour échouée, mais comme il n’y avait pas beaucoup de discussions à ce sujet ici, et que j’ai finalement réussi à charger notre application, j’ai choisi de les ignorer jusqu’à présent.
Voici un exemple :
warning " > @glint/environment-ember-loose@1.0.2" has unmet peer dependency "@glimmer/component@^1.1.2".
warning " > @glint/environment-ember-template-imports@1.0.2" has unmet peer dependency "ember-template-imports@^3.0.0".
warning " > @mixer/parallel-prettier@2.0.3" has unmet peer dependency "prettier@^2.0.0".
warning Resolution field "babel-plugin-ember-template-compilation@2.0.0" is incompatible with requested version "babel-plugin-ember-template-compilation@^2.0.1"
warning Resolution field "unset-value@2.0.1" is incompatible with requested version "unset-value@^1.0.0"
warning " > babel-plugin-debug-macros@0.4.0-pre1" has unmet peer dependency "@babel/core@^7.0.0".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3@3.0.6" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3-multipart@3.1.3" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/xhr-upload@3.1.1" has incorrect peer dependency "@uppy/core@^3.1.2".
warning "workspace-aggregator-a96edb02-ebd3-494c-9d78-028c6a7e5bb3 > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0" has incorrect peer dependency "@uppy/core@^3.2.1".
Ceci est fait avec tous les plugins sauf Docker Manager désactivés dans mon fichier app.yml.
La discussion la plus similaire que j’ai trouvée suggérait que le problème de reconstruction pourrait être dû au fait que notre droplet a été créé il y a de nombreuses années et que c’est là que nous sommes en retard sur toutes ces versions, donc la meilleure solution est de créer un nouveau droplet et de migrer.
Je ne sais pas pourquoi vos mises à jour ne fonctionnent pas et je pense que les messages que vous voyez ne sont pas liés : ce sont des avertissements, pas des erreurs.
Quel genre de « bidouillage » ?
Réinstaller Discourse sur un nouveau serveur est assez facile et rapide (en fonction de la taille de votre forum, bien sûr), vous pourriez donc aussi le faire, cela pourrait résoudre le problème non identifié. Si j’étais vous, j’aimerais bien savoir quel est le problème, cependant.
Eh bien, nous avons une balise répétée d’une manière ou d’une autre et cela empêche l’application de se reconstruire, ce que je peux corriger en suivant ce guide :
.. mais je ne peux pas entrer dans l’application pour la corriger car elle ne fonctionne pas et ne démarrera ni ne se reconstruira.
Je pensais que cela pourrait être dû à ces erreurs, et parce que notre Docker et notre Ubuntu sont un peu datés.
Je suppose que je vais essayer de lancer une nouvelle instance Discourse sur une nouvelle goutte, d’installer Discourse, puis de restaurer notre dernière sauvegarde dedans via la ligne de commande afin de pouvoir, espérons-le, corriger la balise répétée dans la base de données et recharger l’application.
J’aimerais également connaître la raison de ces avertissements, car après les avoir vus, ma compilation échoue également.
111:M 25 Sep 2023 23:13:54.237 # Redis est maintenant prêt à quitter, au revoir...
/usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `readlines': Interrupt
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:110:in `block in spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `popen'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:103:in `spawn'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:80:in `block in run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:78:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/command.rb:8:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:152:in `block (2 levels) in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:142:in `block in run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `each'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:141:in `run_commands'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/config.rb:124:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/cli.rb:65:in `run'
from /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/bin/pups:9:in `<top (required)>'
from /usr/local/bin/pups:25:in `load'
from /usr/local/bin/pups:25:in `<main>'
J’étais sur la version stable 3.1.1, j’ai modifié le fichier app.yml pour inclure le plugin d’exploration de données et maintenant cela échoue. Je n’ai pas effectué de reconstruction complète depuis un certain temps, j’ai seulement utilisé la console d’administration Web pour mettre à jour Discourse et je n’ai jamais eu de problème jusqu’à maintenant. Le système Ubuntu est à jour sur tous les paquets.
MISE À JOUR : La reconstruire une deuxième fois a semblé résoudre le problème, les avertissements apparaissent toujours mais la reconstruction s’est terminée avec succès. Il serait intéressant de savoir pourquoi les avertissements apparaissent maintenant et leur impact (le cas échéant).
Il existe de nombreuses façons de résoudre ce problème avant qu’il ne dégénère. Normalement, vous pouvez reconstruire, ou recharger une sauvegarde précédente et corriger le doublon dans la zone d’administration. Le mien a dégénéré, voici un scénario catastrophe pour corriger manuellement la base de données si cela vous arrive un jour :
