fix: Don't overwrite dep directories in docker-compose'ed containers

[joshlarson]

Summary of changes

By mounting .. into /app, we were overwriting the deps/ directory in the containers with whatever was in the repository when running docker-compose. That means that the results from the build steps in the dockerfiles were being overwritten. A particularly annoying effect is that if you run docker-compose -f deploy/dev.yml up on a fresh clone, then even though the build step does fetch and build dependencies, /app/deps is missing, and the app doesn't start.

This fixes that by explicitly re-mounting the image's /app/deps folder into the container, regardless of what's in ..:/app

---

General checks

• Are the changes organized into self-contained commits with descriptive and well-formatted commit messages? This is a good practice that can facilitate easier reviews.
• Testing. Do the changes include relevant passing updates to tests? This includes updating screenshots. Preferably tests are run locally to verify that there are no test failures created by these changes, before opening a PR.
• Tech debt. Have you checked for tech debt you can address in the area you're working in? This can be a good time to address small issues, or create Asana tickets for larger issues.

New UI, or substantial UI changes

• Cross-browser compatibility is less of an issue now that we're no longer supporting IE, but changes still need to work as expected in Safari, Chrome, and Firefox.
• Are interactive elements accessible? This includes at minimum having relevant keyboard interactions and visible focus, but can also include verification with screen reader testing.
• Other accessibility checks such as sufficient color constrast, or whether the layout holds up at 200% zoom level.

New endpoints, or non-trivial changes to current endpoints

• Have we load-tested any new pages or internal API endpoints that will receive significant traffic? See load testing docs
• If this change involves routes, does it work correctly with pertinent "unusual" routes such as the combined Green Line, Silver Line, Foxboro commuter rail, and single-direction bus routes like the 170?

[thecristen]

works on a fresh install! thanks so much

[anthonyshull]

Can we make sure it works when upgrading a dependency and changing config?

[joshlarson]

@anthonyshull changing config works the same as before - a simple docker compose restart dotcom-1 dotcom-2 will work (I have validated this)

I think updating a dependency will require docker compose down; docker compose up --build. Any deps in particular that I can/should test this out with?

If we would prefer docker compose restart to also pick up new deps, we can add mix deps.get to the CMD step. We still gain by keeping it earlier in the Dockerfile as well, because if the image's deps are up-to-date, then mix deps.get in the CMD will just breeze through the cache.

[anthonyshull]

I think updating a dependency will require docker compose down; docker compose up --build. Any deps in particular that I can/should test this out with?

Any dep should be fine; we want to make sure it picks up the change.

[joshlarson]

down and then up picks up dependency changes.

I have a few other ideas for how to speed this up more, but those can be follow-up tasks.

[joshlarson]

@thecristen in case it affects your approval, I added another commit

[thecristen]

Sounds good to me @joshlarson ! 👍🏼