Skip to content

[bug]: When creating local development environment, the API, Proxy and Beat Worker containers fail to start successfully. #3198

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
tonyeggers opened this issue Dec 19, 2023 · 1 comment

Comments

@tonyeggers
Copy link

tonyeggers commented Dec 19, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

API: exec ./bin/takeoff.local: no such file or directory
Proxy: exec /docker-entrypoint.sh: no such file or directory
Beat Worker: relation "django_celery_beat_periodictask" does not exist

Couldn't get to work on my desktop, and tried a clean install on a laptop using only Git Bash (Docker 4.25.2). No changes to .env files but same result.

As an example for the API container, files indeed do not exist in the code working directory (see image). Obviously, connecting to the database container (after mapping the port) with pgAdmin shows database instance created but no tables created.

image

I am able to successfully get a self-hosted version operational locally on Docker Desktop. Reviewed the Docker files and see the differences with the .dev versions but not sure what the problem is and thought to check first before spending additional troubleshooting time.

Steps to reproduce

1: git clone https://github.com/makeplane/plane.git
2: cd plane
3: ./setup.sh
4: docker compose -f docker-compose-local.yml up -d

Browser

Google Chrome

Version

Local

Keywords

  • files not accessible in container
  • folders not mounted
  • local development environment not working
  • clean install doesn't work
  • database tables not created
  • SQL query fails
  • working directory not populated

Related (Possible)

#3105

@tonyeggers
Copy link
Author

tonyeggers commented Dec 21, 2023

The issue here is the same as reported in #834. Updated startup sh files to be LF (instead of CRLF) and containers started successfully. I didn't find the old issue (April) initially because the sh file was originally named exec ./bin/takeoff and I was searching for exec ./bin/takeoff.local.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant