NoMongo: Talawa App Not Starting Using Docker on develop-postgres Branch

[prayanshchh]

Describe the bug
The Talawa app fails to start when using Docker Compose on the develop-postgres branch. The api container exits with an error due to a missing vitest command. The postgres-test and minio-test containers appear to start successfully, but the application cannot proceed due to the error in the API container.

To Reproduce
Steps to reproduce the behavior:

1 .Clone the Talawa repository and switch to the develop-postgres branch.
2. Run docker compose up to start the application.
3. Observe the logs.

Expected behavior
The application should start successfully, with all containers running and the API functional.

Actual behavior
The api container exits with the following error:

api-1            | sh: 1: vitest: not found
api-1            |  ELIFECYCLE  Command failed.
api-1 exited with code 1

Screenshots

Additional details
Add any other context or screenshots about the feature request here.

Potential internship candidates

Please read this if you are planning to apply for a Palisadoes Foundation internship

• Student Internship Programs talawa#359

[prayanshchh]

assign

[xoldd]

@prayanshchh The development environment isn't meant to be booted up with docker compose up, it's meant to be booted up with vscode devcontainers. Follow the video: https://youtu.be/jz7koJIXqtk?feature=shared

[palisadoes]

@xoldd

We cannot be dictating the IDE of persons contributing to the project. There must be also be a universal way for coders to participate

[prayanshchh]

should this be closed as well?

as we aren't using docker for setup.

[xoldd]

@xoldd

We cannot be dictating the IDE of persons contributing to the project. There must be also be a universal way for coders to participate

I think it is perfectly reasonable to do this as it will save a lot of time that is otherwise wasted on platform specific issues that contributers would have to deal with. The workflows are also harder to manage when the application is meant to run on a different platform than the development platform.

[xoldd]

A less restrictive way would be for developers to work on their local platform and those changes being synced to the docker containers. There's this new docker compose watch feature for this. But again, this would require for developers to learn more about docker because they'd have to interface with the containers using docker specific commands. Or they'd have to exec into the docker container's shell which again is the same thing that devcontainer is doing.

Devcontainers are like a very lightweight virtual machine with less features than a virtual machine but ideal for most development specific use cases that aren't related to graphics programming in some way. Devcontainers can be made more universal using tools like devpod but vscode simply has the best integration for devcontainers which is mostly hassle free.