He visto algunas migraciones de configuración recientemente (la más reciente fue la eliminación de automatic_backups_enabled) donde la migración utiliza solo valores de la base de datos para calcular un nuevo valor. Esto ignora cualquier configuración realizada en discourse.conf a través de app.yml.
Código:
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()';
lo que ignora automatic_backups_enabled = false en discourse.conf y, como resultado, no mantiene las copias de seguridad deshabilitadas cuando esa configuración está presente.
Este barco específico ya zarpó, pero podría ser útil tener en cuenta que este patrón causa problemas con las configuraciones que se anulan globalmente.
Sí, GlobalSetting se carga durante las migraciones
Tampoco creo que quieras depender de una variable de entorno en tiempo de compilación. Hace que sea difícil separar el paso de la variable de entorno a discourse.conf y el despliegue real del contenedor. En mi otro mundo (PHP/Laravel) esto se considera un anti-patrón.