Fix: use correct storage directory for client service

[angela-tran]

Closes #2620

This PR adds volume mappings to bring in django.db and the uploads folder into /home/calitp/app/data inside the client service.

Explanation

It needs to be this specific path is because the client container needs DJANGO_STORAGE_DIR to be /home/calitp/app/data so that nginx can serve media files correctly. But then, the client container fails to start because there is no database file at /home/calitp/app/data.

This volume mapping gives the container access to the django.db file and the uploads/ directory from the host side of the mapping.

[github-actions]

Coverage report

This PR does not seem to contain any modification to coverable code.

[thekaveman]

I'm confused why this is required? What problem are we trying to solve here? I'm able to bring up docker compose up -d client on the main branch on my machine.

I thought DJANGO_STORAGE_DIR was more of a deployment config (i.e. not really for devtime).

I don't have this setting in my local .env, so maybe that is why it works for me?

[angela-tran]

Yeah, so you're right that when running client locally, it's not strictly necessary to set DJANGO_STORAGE_DIR. When that env variable isn't set, settings.py will use BASE_DIR, i.e. the working directory, as STORAGE_DIR.

If you run docker compose -d client in that state, the app will come up just fine and use django.db at your project root. Because django.db isn't copied into the app container, an empty database is created by the migration part of the init script. You can start a bash session inside the running container and run ./bin/reset_db.sh to load our sample fixtures into the database.

But then you'll notice that the media files return 404s. And that's the main problem that needed to be solved here.

It was kind of a chain of problems that led to this change, so I totally understand the need for more clarification.

[angela-tran]

I just edited the title of #2620 to be more accurate / descriptive 😅

[thekaveman]

OK thank you -- I did see a missing agency logo on the modal selector before this PR, and now I see the agency logo 👍

One comment, the effect of this is to have the entire source directory mounted under /home/user/calitp/app/data. Is there any way to reduce this? It takes us away from client which is supposed to really be a clean runtime. I.e. could we mount in just the ./uploads directory or some other subset?

[angela-tran]

One comment, the effect of this is to have the entire source directory mounted under /home/user/calitp/app/data. Is there any way to reduce this? It takes us away from client which is supposed to really be a clean runtime. I.e. could we mount in just the ./uploads directory or some other subset?

Great suggestion. Turns out we can map files too, so I updated it to only bring in django.db and the uploads directory: ea3e18a

[thekaveman]

I was worried this would break if django.db did not exist. But that doesn't appear to be the case, the client service still comes up OK.

However, if django.db does not exist, a local directory called django.db is created upon service startup:

So that isn't what we want. Recall our goal with client has been it should mostly work OOTB -- create an .env file and docker compose up client. Of course this doesn't work as well in the world where we have a stable database file in prod but no such thing locally.

Can we think about this one a little more?