Nouvelle installation échoue (installation neuve)

Potentiellement lié à 147425, mais j’ai ouvert un nouveau fil car mon cas concernait une installation neuve et non une migration.

J’ai essayé sur deux instances Ubuntu 18.04 propres et distinctes (une chez Linode, une chez Digital Ocean) pour configurer une installation autonome via le script Docker. À chaque fois, j’ai obtenu la même erreur.

Capture d’écran de l’erreur

Affichage de l’erreur

== 20180917024729 RemoveSuperfluousColumns: migration en cours =========================

AVERTISSEMENT
-------------------------------------------------------------------------------------
Une tentative a été faite pour supprimer ou renommer une colonne lors d'une migration
La commande SQL utilisée était : 'ALTER TABLE user_profiles DROP COLUMN IF EXISTS card_image_badge_id'

Veuillez générer une migration post-déploiement en utilisant `rails g post_migration` pour supprimer
ou renommer des colonnes.

Note : pour minimiser les perturbations, utilisez self.ignored_columns = ["nom de la colonne"] sur votre
modèle ActiveRecord ; cela pourra être supprimé environ 6 mois plus tard.

Cette protection est en place pour nous protéger contre la suppression de colonnes actuellement
utilisées par des applications en production.

I, [2020-04-09T15:07:30.875957 #1]  INFO -- : Terminaison des processus asynchrones
I, [2020-04-09T15:07:30.876041 #1]  INFO -- : Envoi de INT à HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/10/bin/postmaster -D /etc/postgresql/10/main pid: 64
2020-04-09 15:07:30.876 UTC [64] LOG:  demande d'arrêt rapide reçue
I, [2020-04-09T15:07:30.876354 #1]  INFO -- : Envoi de TERM à exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 181
181:signal-handler (1586444850) SIGTERM reçu, planification de l'arrêt...
181:M 09 Apr 2020 15:07:30.954 # Arrêt demandé par l'utilisateur...
181:M 09 Apr 2020 15:07:30.954 * Sauvegarde du dernier instantané RDB avant la sortie.
181:M 09 Apr 2020 15:07:30.959 * Base de données sauvegardée sur le disque
181:M 09 Apr 2020 15:07:30.960 # Redis est maintenant prêt à quitter, au revoir...
2020-04-09 15:07:30.880 UTC [64] LOG:  annulation de toutes les transactions actives
2020-04-09 15:07:30.886 UTC [64] LOG:  processus worker : lanceur de réplication logique (PID 73) terminé avec le code de sortie 1
2020-04-09 15:07:30.894 UTC [68] LOG:  arrêt en cours
2020-04-09 15:07:31.151 UTC [64] LOG:  le système de base de données est arrêté


ÉCHEC
--------------------
Pups::ExecError : cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' a échoué avec le code de retour #<Process::Status: pid 12943 exit 1>
Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn'
Échec de l'exécution avec les paramètres {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
90378b39f271ddf9c4ba2628e28ceffd9ede8f3c6cdb4815b12f8b3ae5a218ac
** ÉCHEC DU BOOTSTRAP ** veuillez faire défiler vers le haut et rechercher les messages d'erreur antérieurs, il peut y en avoir plusieurs.
./discourse-doctor peut aider à diagnostiquer le problème.

Nous avons annulé les commits concernés, pouvez-vous réessayer ?

1 « J'aime »

Oui, je dois basculer le DNS, cela prendra donc environ une heure. Je reviens vers vous. Merci.

Oui, @sam examinera cela lundi prochain en Australie.

1 « J'aime »

J’ai réussi à installer correctement. Merci pour l’aide !

Je regarderai lundi, cela n’a pas de sens car j’avais un commit spécifique qui évitait de charger le code

3 « J'aime »

Corrigé conformément à :

Zeitwerk chargeait automatiquement cela car nous avions des migrations qui exécutaient des remplacements sur SafeMigrate.

J’ai désactivé cela dans la classe.

4 « J'aime »