What is the correct way to update after a docker compose installation?

[Dan1ell]

On the main page under Update it says:

If you've used the above way to install MediaCMS, update with the following:

cd /home/mediacms.io/mediacms # enter mediacms directory
source  /home/mediacms.io/bin/activate # use virtualenv
git pull # update code
python manage.py migrate # run Django migrations
sudo systemctl restart mediacms celery_long celery_short # restart services

But based on the mentioned mediacms directory and the fact systmctl is missing after a docker compose installation, these instructions seem like they are only for the single server installation.

What are the correct update instructions for the docker compose installation?

[swiftugandan]

I think docker pull mediacms/mediacms:latest then docker-compose down && docker-compose up should get the latest image and restart the application using the new image.

[Dan1ell]

Ok, looks similar to what I'm doing, but the issue I'm having during the update process is that 'docker-compose up' always loads the fixtures and the categories fixture keeps resetting my categories list.
So, how to update mediacms without running the fixtures?

[swiftugandan]

mediacms/deploy/docker/prestart.sh

Line 8 in 04f59ff

python manage.py loaddata fixtures/encoding_profiles.json

looks like we need to check if that data exists before running the fixture!

Or use a "LOAD_INITIAL_DATA" variable that the user can set in the migrations service environment

[Dan1ell]

Yeah, initial data should really only load initially. When some data is already present in the intended table or column, initial data should not be loaded again. But the user should be able to override this behavior with a variable, perhaps for use in the dev environment, to intentionally reset test data.

Regarding the variable, I think "LOAD_INITIAL_DATA" might not be the right name for this yes/no variable since you pretty much always want to load initial data when it’s actually the first time it’s going to load; so on installation but also later whenever a new migration runs for the first time to add a model or add a field. If that change came with some initial data, you would want it. So the answer would always be ‘yes’, I want to load initial data.

A better name might be RELOAD_INITIAL_DATA because it is clear that setting this variable to ‘no’ does not prevent the first loading of fixture data, it’s about a reload, it loads the fixture data even if data is already there.

And I think if RELOAD_INITIAL_DATA is set to ‘yes’, it should replace the data that is already there not just concatenate to it like it’s doing now. Because I would use it to reset the test data. So maybe RESET_INITIAL_DATA is also good.

Because the way I see this being used is so on dev we can automatically start with fresh test data after every update and we can add our own fixtures and list them in the prestart.sh so that they are also controlled by this variable.

Or we can list our fixtures in the settings file and prestart.sh will be modified to look for this list in settings.

[swiftugandan]

Please create an issue so we don't lose track of it

…

On Sun, 28 Mar 2021, 19:32 Dan1ell, ***@***.***> wrote: Yeah, initial data should really only load initially. When some data is already present in the intended table or column, initial data should not be loaded again. But the user should be able to override this behavior with a variable, perhaps for use in the dev environment, to intentionally reset test data. Regarding the variable, I think "LOAD_INITIAL_DATA" might not be the right name for this yes/no variable since you pretty much always want to load initial data when it’s actually the first time it’s going to load; so on installation but also later whenever a new migration runs for the first time to add a model or add a field. If that change came with some initial data, you would want it. So the answer would always be ‘yes’, I want to load initial data. A better name might be RELOAD_INITIAL_DATA because it is clear that setting this variable to ‘no’ does not prevent the first loading of fixture data, it’s about a reload, it loads the fixture data even if data is already there. And I think if RELOAD_INITIAL_DATA is set to ‘yes’, it should replace the data that is already there not just concatenate to it like it’s doing now. Because I would use it to reset the test data. So maybe RESET_INITIAL_DATA is also good. Because the way I see this being used is so on dev we can automatically start with fresh test data after every update and we can add our own fixtures and list them in the prestart.sh so that they are also controlled by this variable. Or we can list our fixtures in the settings file and prestart.sh will be modified to look for this list in settings. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#115 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFQ5FI6J5FZGTHDKB7JEELTF5Y3LANCNFSM4Z5HJ3HQ> .