Discourse_docker : l'amorçage du lanceur échoue (solution de contournement incluse)

L’initialisation d’une nouvelle image de conteneur échoue. Cela fonctionnait il y a quelques jours, « rien n’a changé », mais aujourd’hui cela échoue. Journal :

[0:02:27] Toujours en cours de traitement :
[0:02:27]   v8
________ exécution de 'vpython third_party/depot_tools/update_depot_tools_toggle.py
--disable' dans
'/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor/depot_tools/.cipd_bin/.cipd/pkgs/0/fI6WggdkRyN1r91MnTeApc2_gyTtXfYpueHZVLcaF8gC/vpython:
impossible de résoudre les options : échec de la résolution du script Python : stat
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor/third_party/depot_tools/update_depot_tools_toggle.py:
fichier ou répertoire introuvable
Erreur : La commande 'vpython third_party/depot_tools/update_depot_tools_toggle.py
--disable' a renvoyé un statut de sortie non nul (1) dans
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor

...

** ÉCHEC DE L'INITIALISATION ** Veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents ; il peut y en avoir plus d'un.
./discourse-doctor peut aider à diagnostiquer le problème.

En creusant le problème : Pour libv8, un problème similaire a déjà été signalé sur GitHub, lié à un changement de version dans le builder Ruby. Lors de l’initialisation, une mise à niveau du builder est effectuée. Je pense que le problème semble être lié à la version 2.2.15 de bundler (publiée hier). Pour être honnête : je ne suis pas un expert Ruby, donc peut-être que le vrai problème est légèrement différent.

Cependant, la solution de contournement suivante a fonctionné pour moi : Modifiez la ligne 148 dans templates/web.template.yml en remplaçant
- gem update bundler
par
- gem install bundler -v 2.2.14

Cordialement,

Michael

C’était lors de la tentative de construction sur la branche stable ?

Bonne remarque ! Branche master de discourse_docker, paramètres : version : stable dans app.yml

À moins que vous ayez une raison d’exécuter stable et que vous soyez prêt à accorder une attention particulière à certains aspects (comme ce problème), vous serez mieux loti avec tests-passed. Il est beaucoup mieux testé et c’est celui que Discourse utilise pour son hébergement.

Cela mérite certainement d’être débogué. Si Bundler vient de publier un bogue, nous devons mettre en place rapidement une solution de contournement.

@kris.kotlarek peux-tu reproduire le problème sur DigitalOcean ?

Plusieurs problèmes sont en jeu ici. Pour l’instant, la solution la plus fluide consiste à mettre à jour la version du Gemfile dans la branche stable. Consultez le message de commit pour plus de détails :

@m.abi, veuillez essayer de reconstruire à nouveau — cela devrait fonctionner maintenant.

Je m’attends à ce que celui qui fonctionne sur la version stable bénéficie de plus, eh bien, de stabilité — idéalement des correctifs de sécurité et peu d’autre chose. Du moins, c’est ainsi que nous interprétons la branche stable. Et il n’est pas nécessaire de prêter plus d’attention à la version stable car elle pourrait se briser plus souvent que la version de pointe.

Eh bien, comme le montre ce cas, les choses sont un peu moins comme vous pourriez le penser. Ils font du bon travail pour corriger les problèmes rapidement (comme celui-ci), mais ils ne stable pas (majoritairement ?) sur leur propre hébergement, donc c’est un peu moins bien testé que tests-passed. Sauf juste après une nouvelle version stable, je considère que tests-passed est un choix un peu plus « sûr ». Tout le monde n’est pas d’accord.

@david La build fonctionne ! Merci !