La reconstruction échoue avec git reset --hard origin tests-passed a échoué avec le retour

Soutien
1

Je exécute Discourse dans un conteneur Docker et lorsque j’essaie d’utiliser le launcher pour reconstruire app.yml, je rencontre cet échec :

ÉCHEC
--------------------
Pups::ExecError : cd /var/www/discourse && git reset --hard origin tests-passed a échoué avec le retour #<Process::Status: pid 257 exit 128>
Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn'
L'exécution a échoué avec les paramètres {"cd"=>"$home", "hook"=>"code", "cmd"=>["git remote set-branches --add origin master", "git remote set-branches origin $version", "git fetch --depth 1 origin $version", "git checkout $version", "git reset --hard origin $version", "git clean -f", "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,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", "find public/plugins/ -maxdepth 1 -xtype l -delete"]}
a84cc388fbc4b16307c2081e17b03c5eee578e1155fa1e057147601119d89a34
** ÉCHEC DE L'INITIALISATION ** veuillez 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.
==================== FIN DU JOURNAL DE RECONSTRUCTION ====================

Il semble s’agir d’une erreur git liée à l’état actuel du dépôt officiel de Discourse sur GitHub, mais je ne connais pas suffisamment Docker ou Git pour en être certain. J’ai tenté d’exécuter ./discourse-doctor comme suggéré, mais cela a entraîné la répétition du même problème… aucune aide.

2

Bon, alors oui… il y avait un problème avec le dépôt Discourse parce que je n’ai rien fait de spécial… j’ai simplement relancé la reconstruction et maintenant ça marche…

  1. C’est effrayant qu’un état de dépôt corrompu puisse faire planter toute votre configuration.

  2. C’est aussi effrayant qu’il n’y ait pas de récupération par retour en arrière lorsque les dépôts distants ne coopèrent pas… tout le forum affichait une erreur 502 Bad Gateway jusqu’à ce qu’il se reconstruise avec succès. Peut-être qu’il existe quelque chose dans Docker, comme un historique d’images ou autre, qui pourrait être restauré… je ne sais pas… mais il semble que la prise en charge du retour en arrière serait quelque chose de très important si la différence entre le fonctionnement de votre site et son arrêt dépend entièrement de l’état correct des dépôts GitHub. Bien sûr, on pourrait argumenter que c’est à moi de faire une snapshot du serveur avant d’essayer une reconstruction… on pourrait argumenter ça, je suppose.

3

Si la reconstruction échoue, vous pouvez généralement

./launcher start app
4

Merci Jay,

Le conteneur démarrait… J’ai pu utiliser docker top pour voir Nginx s’exécuter à l’intérieur du conteneur, et c’est cette instance qui renvoyait l’erreur HTTP 502 « Bad Gateway ». J’ai confirmé en arrêtant le conteneur et en obtenant ensuite une « connexion refusée », ce qui prouve que le conteneur était bien en cours d’exécution… mais que Discourse échouait à se lancer correctement.

Cependant, est-ce que vous dites qu’en utilisant l’utilitaire launcher, l’application Discourse devrait démarrer à l’intérieur du conteneur ? Ou faudrait-il l’exécuter depuis l’intérieur du conteneur lui-même ?

Désolé pour mon ignorance ici.

5

Je dis que si la reconstruction échoue, vous pouvez généralement lancer l’ancien conteneur avec la commande start.

Il faut un certain temps à Rails pour démarrer, donc l’erreur 502 est attendue pendant une ou deux minutes.