Erreur de mise à jour Docker

J’ai essayé de mettre à jour Docker via mon panneau de contrôle Discourse mais toutes ont échoué, quelqu’un peut-il m’aider ?

/var/www/discourse/lib/discourse_ip_info.rb:48:in `mmdb_download': undefined method `path' for nil:NilClass (NoMethodError)

    filename = File.basename(gz_file.path)
                                    ^^^^^
	from /var/www/discourse/lib/tasks/maxminddb.rake:72:in `block (3 levels) in <main>'
	from /var/www/discourse/lib/tasks/maxminddb.rake:70:in `each'
	from /var/www/discourse/lib/tasks/maxminddb.rake:70:in `block (2 levels) in <main>'
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:210:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:111:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.8.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.8.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.1/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.3.1/lib/thor.rb:527:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.8.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.8.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.8.1/lib/rails/commands.rb:18:in `<main>'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.18.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Spinning up 7 Unicorn worker(s) that were stopped initially

De plus, un avertissement apparaît désormais dans mon installation : Sidekiq ne fonctionne pas. De nombreuses tâches, telles que l’envoi d’e-mails, sont effectuées de manière asynchrone par Sidekiq. Assurez-vous qu’au moins un processus sidekiq est en cours d’exécution. En savoir plus sur Sidekiq ici.

C’est le journal des plantages de maxmind qui bug, commenter la clé API dans votre app.yml et reconstruire devrait résoudre le problème.

Référence au sujet à ce sujet :

1 « J'aime »

Si cela résout le problème, je qualifierais toujours cela de bug, car un échec de téléchargement de Maxmind en raison d’une clé Maxmind invalide, d’une erreur réseau intermittente ou de toute autre raison ne devrait pas faire planter Discourse.

Comme je l’ai mentionné sur votre sujet, la dernière fois que j’ai essayé, nous ne pouvions toujours pas reconstruire avec une clé maxmind valide, ne serait-ce pas le même bug ?

1 « J'aime »

Je dirais que chaque fois qu’un problème avec Maxmind provoque l’échec d’une reconstruction, c’est un bug. Je suis à peu près sûr qu’il a toujours été possible que des problèmes avec Maxmind provoquent l’échec d’une construction.

Donc, je ne sais pas si c’est le même bug ou plusieurs bugs.

Je pense que la solution pourrait être aussi simple que d’ajouter un rescue (quelque part dans discourse/lib/discourse_ip_info.rb at 3d49df2953fd14ae75eeab7621ad687f1b06f504 · pfaffman/discourse · GitHub) pour permettre à la vie de continuer sans Maxmind, qu’une clé, valide ou invalide, ait été fournie ou non.

2 « J'aime »