Closed am-beta closed 1 year ago
Pour moi ce n'est pas vraiment un bug. Y'a aucune raison d'effectuer des migrations et/ou un schema load sur une app vierge, vu que ça sera écrasé no matter what.
Le fix ici est "trivial" : suffit de supprimer tous les fichiers de migration 🤷
Sur une machine qui vient d'être installée, par exemple, il y aura un premier déploiement applicatif, et c'est ce déploiement qui est censé créer la structure de la base (Ansible ne crée pas les tables). S'il échoue, la seule façon de recréer la structure de la base est d'aller chercher sur l'autre machine ou depuis une sauvegarde. C'est faisable mais ça me semble bancal.
De mémoire, jusqu'à récemment j'ai toujours pu déployer l'application sur une installation vierge sans problème.
Je vois très bien le problème que tu évoques, cependant pour nous il n'existe pas : à aucun moment on repart d'une db sans avoir à charger une backup.
Le "fix" que je propose va fonctionner pour un fresh deployment, et ne changera rien pour les futures migrations/setup de machine de dev/dev ..
Les alternatives (qui me semblent useless d'un point de vue fonctionnel):
Pour le dernier point on pourrait à la limite surcharger le mina setup
avec un rails db:schema:load
.. mais quand bien même ça ne sert à rien car l'app ne serait pas fonctionnel ( vu qu'on a eu la "bonne" idée de mettre de la données en dur dans les tables 😅 ) (et d'ailleurs.. on utilise encore mina setup
?)
Qu'est-ce qui soudainement rend cela un peu compliqué, alors qu'il me semble que depuis 2 ans ce problème ne s'est jamais posé, sachant que j'ai fait quand même un paquet de déploiements sur des installations vierges ?
Et oui j'utilise toujours mina setup
, pareil c'est utile sur une installation fraiche. Ceci dit, ça doit être supprimable assez facilement en mettant les créations de répertoires dans Ansible, qui en a déjà un bon paquet mais il en manque sans doute quelques uns.
Qu'est-ce qui soudainement rend cela un peu compliqué, alors qu'il me semble que depuis 2 ans ce problème ne s'est jamais posé, sachant que j'ai fait quand même un paquet de déploiements sur des installations vierges ?
Ce n'est pas compliqué, faut juste supprimer les fichiers inutiles (i.e. les fichiers de migration) car ça n'apporte rien fonctionnellement.
(et ça ne marche plus maintenant car JwtAPIEntreprise
a été renommé en Token
, et ça fait maintenant 7 mois 258c9790)
(et renommer des constantes ça se fait souvent sur une code base, si on doit maintenir des migrations à chaque fois c'est vraiment perdre son temps car une migration c'est du code mort dès que celle-ci a été migré)
J'ai fait une PR dans ce sens: https://github.com/etalab/admin_api_entreprise/pull/848
A tester en sandbox, si c'est OK ça peut partir en "prod"
Je viens de tester, le déploiement se passe bien sur une base vierge. Merci !
J'ai aussi testé (par acquis de conscience) sur une app up-to-date ça fonctionne.
Je close donc.
Sur une base de données complètement vierge (aucune table et bien entendu aucune donnée), le déploiement de la branche
develop
échoue lors de l'étape de la migration.Si avant le déploiement j'importe les données de la base depuis l'autre machine où la même application tourne, alors le déploiement se passe bien.
Même avec une base vierge, il ne devrait pas y avoir d'erreur au déploiement.
Voici les erreurs affichées :