Ich habe kürzlich einige Einstellungen-Migrationen gesehen (die jüngste war die Entfernung von automatic_backups_enabled), bei denen die Migration nur Datenbankwerte verwendet, um einen neuen Wert zu berechnen. Dies ignoriert alle Einstellungen, die in discourse.conf über app.yml vorgenommen wurden.
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()';
was automatic_backups_enabled = false in discourse.conf ignoriert und infolgedessen Backups nicht deaktiviert lässt, wenn diese Einstellung vorhanden ist.
Dieses spezielle Schiff ist abgefahren, aber es ist vielleicht gut zu bedenken, dass dieses Muster Probleme mit global überschriebenen Einstellungen verursacht.
Ja, GlobalSetting wird während der Migrationen geladen
Ich glaube nicht, dass Sie sich auch auf eine Build-Time-Umgebungsvariable verlassen wollen? Es macht es schwierig, den Schritt von der Umgebungsvariable zu discourse.conf und die eigentliche Containerbereitstellung zu trennen. In meiner anderen Welt (PHP/Laravel) wird dies als Anti-Muster angesehen.