J’ai vu quelques migrations de paramètres récemment (la plus récente étant la suppression de automatic_backups_enabled) où la migration utilise uniquement les valeurs de la base de données pour calculer une nouvelle valeur. Cela ignore tous les paramètres définis dans discourse.conf via app.yml.
Code :
INSERT INTO site_settings (name, data_type, value, created_at, updated_at)
SELECT 'backup_frequency', 3, NULL, 'NOW()', 'NOW()'
WHERE EXISTS (
SELECT 1
FROM site_settings
WHERE name = 'automatic_backups_enabled'
AND VALUE = 'f'
LIMIT 1
)
ON CONFLICT (name) DO UPDATE SET value = NULL, updated_at = 'NOW()';
ce qui ignore automatic_backups_enabled = false dans discourse.conf et, par conséquent, ne maintient pas les sauvegardes désactivées lorsque ce paramètre est présent.
Ce navire spécifique a apparemment levé l’ancre, mais il pourrait être bon de garder à l’esprit que ce modèle cause des problèmes avec les paramètres qui sont remplacés globalement.
Oui, GlobalSetting est chargé pendant les migrations
Je ne pense pas que vous vouliez non plus vous appuyer sur une variable d’environnement au moment de la compilation ? Cela rend difficile la séparation de la variable d’environnement vers l’étape discourse.conf et le déploiement réel du conteneur. Dans mon autre monde (PHP/Laravel), cela est considéré comme un anti-modèle.