Docker module issue Closing #139

[briswells]

No description provided.

[jayrevolinskyjr]

I can confirm that it was a me issue before. I followed Hardik's instructions for cleaning out the containers, images, and volumes and then i ran docker compose build --no-cache and docker compose up and it works for me.

[hardikpatil]

Looks good, worked on my end. Finally!

[hardikpatil]

I tried docker compose build --no-cache and then docker compose up, but I am still receiving the 'Cannot find module 'sequelize'' error, even after cleansing my docker cache, containers, images, and volumes. I am not sure if this is a me issue or from the node modules. I also think we need to update the readme instructions for building.

I faced this yesterday, I had to remove all images, all stopped containers and images
docker image prune -a
docker stop $(docker ps -a -q)
docker rm $(docker ps -a -q)
docker rmi $(docker images -q).

[shubhamlatkar]

I tried docker compose build --no-cache and then docker compose up, but I am still receiving the 'Cannot find module 'sequelize'' error, even after cleansing my docker cache, containers, images, and volumes. I am not sure if this is a me issue or from the node modules. I also think we need to update the readme instructions for building.

I faced this yesterday, I had to remove all images, all stopped containers and images docker image prune -a docker stop $(docker ps -a -q) docker rm $(docker ps -a -q) docker rmi $(docker images -q).

@hardikpatil I wonder where do you got these docker commands from? 🤔
They are very risky and should be used under adult supervision only 😆

[ysiddhapura]

Tested this branch with the changes, deleted old images, ran docker compose build --no-cache, and docker compose-up and runs for me!

[AbhinavReddy-Dev]

@briswells @shubhamlatkar Can you please let us know the right commands to build and run? Looks like adding --no-cache to build command works, but wanted to know if that is the right way of doing it and if there is a need to update the README to let everyone the change in commands to run the container.

[kbuffardi]

Thanks for your work on this.
There are a lot of files changed here so there's a lot to review. It looks like some of it is just shifting files into different directories. However, can you please give us a breakdown of what changes are included (and why)?

To tag onto @AbhinavReddy-Dev's question, is the proposed solution to use the --no-cache option one time, or every time we rebuild/run docker? Along those lines, are there any different directions that should be updated in README.md?

[briswells]

Thanks for your work on this. There are a lot of files changed here so there's a lot to review. It looks like some of it is just shifting files into different directories. However, can you please give us a breakdown of what changes are included (and why)?

To tag onto @AbhinavReddy-Dev's question, is the proposed solution to use the --no-cache option one time, or every time we rebuild/run docker? Along those lines, are there any different directions that should be updated in README.md?

@AbhinavReddy-Dev @kbuffardi Most of the changes are just moving the code from backend into a src folder and updated paths. I update the dockerfile's to copy the tsconfig.json files to their respective containers, updated the mounts in docker-compose to be the src directories and updated the path in backend/package.json to reflect the update with src directory.

Docker compose build --no-cache will only need to be run once to fix any issues with legacy code hanging around in places it's not suppose to be. After that you should only need to run docker compose build when a new node module is installed. Anyone who is building the container fresh would NOT need to run docker compose build --no-cache, just docker compose build

[jayrevolinskyjr]

The README on the main branch is lacking docker compose build as an instruction. I am of the mindset that we should not include the pruning commands on the README since we will be assuming that anyone who clones a fresh repo will not have any dangling images or cache issues related to PantryNode.

[kbuffardi]

I am of the mindset that we should not include the pruning commands on the README since we will be assuming that anyone who clones a fresh repo will not have any dangling images or cache issues related to PantryNode.

100% agree and I'm hoping that the proposed solution only involves pruning images and clearing cache for people currently working on the project. I hope our solution is sustainable and simple. Moreover, as acknowledged in the discussion, those commands might be effective but they are a bit dangerous to suggest to anyone who might want to work on the project in the future -- they involve deleting all images/containers, even those that don't belong to the project. That can be particularly troublesome for people who are also using Docker on other projects.

But if that is a non-issue with the proposed solution... that's a good sign!

[briswells]

I’m going to merge this with main and open a new issue to update the readme, and rename docker containers to more appropriate names.