Change Details

A bin/configure script copies everything deployment specific in the right locations. Notes * We copy because symlinks don't work in docker containers where we sometimes only mount src/ * Artisan commands + config could be included, but aren't atm. * The theme can be included via config/theme * The provided config works for the docker-compose localhost setup, I have another config for a localhost development setup via 127.0.0.1 where kolab4 runs on the host.

A bin/configure script copies everything deployment specific in the right locations. Notes * We copy because symlinks don't work in docker containers where we sometimes only mount src/ * Artisan commands + config could be included, but aren't atm. * The theme can be included via config/theme * The provided config works for the docker-compose localhost setup, I have another config for a localhost development setup via 127.0.0.1 where kolab4 runs on the host. * Most migrations where relatively straightforward to separate between seed/and regular migration, only 2022_05_13_100000_permissions_and_room_subscriptions.php was a bit more involved because it changes the schema, migrates existing data over, and then drops the old data. This is now solved by first running a seed-migration that create the new seed entry (deployment specific), and then run the schema change that generically moves existing data over.

A bin/configure script copies everything deployment specific in the right locations. Notes * We copy because symlinks don't work in docker containers where we sometimes only mount src/ * Artisan commands + config could be included, but aren't atm. * The theme can be included via config/theme * The provided config works for the docker-compose localhost setup, I have another config for a localhost development setup via 127.0.0.1 where kolab4 runs on the host. * Most migrations where relatively straightforward to separate between seed/and regular migration, only 2022_05_13_100000_permissions_and_room_subscriptions.php was a bit more involved because it changes the schema, migrates existing data over, and then drops the old data. This is now solved by first running a seed-migration that create the new seed entry (deployment specific), and then run the schema change that generically moves existing data over.