search

supabase / cli

Supabase CLI. Manage postgres migrations, run Supabase locally, deploy edge functions. Postgres backups. Generating types from your database schema.
https://supabase.com/docs/reference/cli/about
MIT License
1.02k stars 201 forks source link

functions deploy uses container path in host resulting in files not found and failure to deploy #2535

Closed alita-moore closed 1 month ago

alita-moore commented 2 months ago

Describe the bug When you develop a supabase project inside of a devcontainer volume functions deploy will fail to deploy because it attempts to find the files on the host under the same path. However, because these are not necessarily the same it causes it to fail. Local development appears to work normally.

To Reproduce See the following codesandbox. You may setup a sample project to test deployment, but the project demonstrates the devcontainer layout I'm referring to. If you deploy in this environment it will fail to find the files in the host's filesystem.

Expected behavior I expect the deploy script to either pull files from the devcontainer directly or find the respective mapping from the docker container's volume.

System information Rerun the failing command with --create-ticket flag.

Here's the debugging output:

 npx supabase functions deploy --create-ticket --debug
Supabase CLI 1.183.5
Bundling api-consumers
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Sent Header: Content-Length [333]
2024/07/19 07:44:03 Sent Header: Content-Type [application/json]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Sent Header: Content-Length [158]
2024/07/19 07:44:03 Sent Header: Content-Type [application/json]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Sent Header: Content-Length [2812]
2024/07/19 07:44:03 Sent Header: Content-Type [application/json]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Sent Header: Content-Length [0]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
Error: entrypoint path does not exist (/Users/alitamoore/workspaces2/monorepo/infra/supabase-platform/supabase/functions/api-consumers/index.ts)
2024/07/19 07:44:03 Sent Header: Host [api.moby.localhost]
2024/07/19 07:44:03 Sent Header: User-Agent [Docker-Client/unknown-version (linux)]
2024/07/19 07:44:03 Send Done
2024/07/19 07:44:03 Recv First Byte
error running container: exit 1
sweatybridge commented 1 month ago

Unfortunately it's not possible to support this on every OS because the edge runtime binary is only built for linux. So mounting functions directory into the edge runtime container is the least we can do.

But since you are using Ubuntu, an alternative is to write some custom go code to deploy using the edge runtime binary natively. We have published an example here in case you are interested https://github.com/supabase/cli/blob/develop/examples/functions-deploy/main.go

alita-moore commented 1 month ago

For reference my work-around for this has been to make the working directory within my devcontainer match the directory in the host, due to mac's System Integrity Protection (SIP) it's not possible to create a directory on the host that matches within the container (for example, if you had mounted to path /workspaces/app). So instead you'll need to create a directory in the mac user folder and mount off of that within the devcontainer.

# docker-compose.yaml
services:
  workstation:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ${HOME}/workspaces:${HOME}/workspaces