Je tiens à répéter que je n’utilisais pas le programme de mise à jour graphique. J’ai une installation multi-conteneurs. J’ai fait :
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
(J’utilise app pour l’application web, même pour les installations multi-conteneurs. Je sais que ce n’est pas la pratique normale. Je déteste taper web_only)
Un certain temps après avoir lancé bootstrap et avant d’avoir détruit l’application, l’ancienne version fonctionnant avec la nouvelle base de données n’affichait qu’un écran d’erreur. Je ne me souviens pas de son contenu, et je n’ai pas prolongé l’interruption en m’arrêtant pour prendre une capture d’écran avant de détruire/démarrer, mais c’était juste du texte sur fond blanc et ce n’était pas la page de maintenance du système. J’ai vu cela seulement quelques fois auparavant, lorsque le bootstrap exécute db:migrate dans le cadre de la reconstruction asynchrone “sans interruption de service”, le vieux logiciel encore en cours d’exécution échoue en raison d’une incohérence de schéma.
Ce que j’ai vu, c’est ce qui se passe en cas d’incohérence de la base de données. C’est bien mieux que de continuer tranquillement, en cassant la base de données ! Lorsque j’ai posté, c’était pour avertir que c’était l’un de ces rares cas où l’application d’une mise à jour ponctuelle (ici de 3.1.0.beta1 à 3.1.0.beta2) créait une incompatibilité de schéma entre le code 3.1.0.beta1 et la base de données après l’exécution de db:migrate de 3.1.0.beta2, comme cela arrive rarement mais occasionnellement avec les mises à jour normales à faible interruption de service dans le déploiement multi-conteneurs.
Mon expérience est différente de l’erreur signalée avec Ruby dans le programme de mise à jour graphique. C’est un problème complètement indépendant. Je reconnais que mon message a été déplacé de l’annonce vers un fil général “problèmes avec”, mais je tiens à préciser que la raison pour laquelle je l’ai posté dans l’annonce était d’avertir d’autres auto-hébergeurs comme moi lorsqu’ils verraient l’annonce que cette mise à jour particulière pouvait avoir cet impact.
Mon message ne se plaignait pas d’un bug, ni même d’un problème. Il était uniquement destiné à signaler un cas normal mais peu fréquent associé à cette version particulière et non mentionné dans les notes de version.
Les plaintes concernant le gestionnaire docker ne reconnaissant pas qu’il ne peut pas se mettre à jour depuis l’intérieur de l’image sont complètement sans rapport avec ma tentative de fournir une notification utile aux autres administrateurs auto-hébergés.
Il serait très judicieux de séparer ces problèmes non liés en fils de discussion indépendants pour des problèmes indépendants. EDIT par @supermathie : Fait