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.09k stars 212 forks source link

CLI version v1.223.10 breaking change causes deployment GitHub action to fail because of missing smtp setting in config file #2899

Open khera opened 6 days ago

khera commented 6 days ago

Describe the bug A clear and concise description of what the bug is.

Using a GitHub action to push migrations to the hosted instance fails with the current CLI, because it is now fatal to not have an smtp host defined. The local CLI development defaults to in bucket, so this is not set in my config file.

To Reproduce Steps to reproduce the behavior:

Using the following GitHub actions:

jobs:
    supabase-deploy:
        runs-on: ubuntu-latest
        steps:
            - name: Checkout
              uses: actions/checkout@v4
            - name: Prep Supabase CLI
              uses: supabase/setup-cli@v1
              with:
                version: latest
            - run: supabase link --project-ref ${{ inputs.PROJECT_ID }}
            - run: supabase db push

pulls the latest version of the cli, which is v1.223.10 currently. My project locally is still using CLI v1.219.2 where everything works. When running the link command, it fails with this error:

Missing required field in config: auth.email.smtp.host
Try rerunning the command with --debug to troubleshoot the error.

Then it exits.

There's no reason to have the local CLI development configuration set this variable, as it uses inbucket.

Expected behavior A clear and concise description of what you expected to happen.

The deploy should succeed like it always has with my config file, or the version should be bumped for the breaking change.

Screenshots If applicable, add screenshots to help explain your problem.

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

Additional context If applicable, add any other context about the problem here.

khera commented 6 days ago

Clarification: it seems that if any auth.email.smtp settings are made, you now require all (host, port, user, pass) of them to be set.

My current configuration is

[auth.email.smtp]
admin_email = "support@mydomain.com"
sender_name = "MyProject DEV"

Now it is demanding I set all the other fields, but there's no guidance as to what those should be to work with inbucket in the sample config.toml in a new project. I set the following, but the auth service cannot still send any email, it returns 500 error status.

host = "localhost"
port = 54325
user = "email"
pass = "anything"

I also tried host = "host.docker.internal"

It would be helpful to add those notes in the config.toml in a new project, and to have a "migrate" function of the CLI to bring my config file up to current, keeping existing settings I changed.

sweatybridge commented 6 days ago

Thanks for reporting this issue. I wasn't expecting users to configure inbucket [auth.email.smtp] because the original comment was to configure a production ready custom smtp server. However, we also didn't perform any validations previously so this unintentionally became a breaking change.

Going forward, I wouldn't recommend updating smtp to inbucket host and port because those values won't make sense for branching use cases. We are also planning to switch to mailpit for better UI.

But if this is necessary to unblock, you can use the following settings for the time being.

[auth.email.smtp]
host = "inbucket"
post = 2500
user = "anything"
pass = "anything"

I will update this thread again after we come to a firm decision internally.

khera commented 5 days ago

Thanks for the info. I set up the config as you show above, keeping my admin_email and sender_name, (and restarted local dev) but I continue to get the error sending the recovery mail, Error sending recovery email

  status: 500,
  code: 'unexpected_failure'

on the dashboard it shows this in the auth log:

{
  "code": 500,
  "message": "An error has occurred: fetch failed",
  "requestId": "198e150f-4b2e-4234-925b-703a717fad71"
}
avallete commented 3 days ago

I think there's a circular issue between gotrue and inbucket. If you provide a non-empty username/password, it expects encryption to be enabled, which fails with inbucket. The way I got inbucket and SMTP working together was by disabling the validation for SMTP user/password in the cli source code. With this configuration, emails are sent properly to inbucket:

# Use a production-ready SMTP server
[auth.email.smtp]
host = "inbucket"
port = 2500
admin_email = "admin@email.com"
sender_name = "Admin Custom"

Otherwise, as long as smtp.user and smtp.pass are set to non-empty values, the auth container throws a 500 error:

{"user_email":"XXXX@gmail.com","user_id":"56e9b859-970b-4f06-80e7-11f305f4188b"}},"component":"api","error":"unencrypted connection","level":"error","method":"POST","msg":"500: Error sending invite email","path":"/invite","referer":"http://127.0.0.1:3000","remote_addr":"192.168.97.14","request_id":"be3e432d-af74-4f05-b8aa-35dc5df7083a","time":"2024-11-22T14:50:19Z"}

The solution I found to retain SMTP validation and allow email/sender customization is to support sender_name and admin_email under the inbucket section of the configuration. This is a draft proposal as it'll still be a breaking change that'll require config update.

See: https://github.com/supabase/cli/pull/2908

@khera Currently you won't be able to use both inbucket and smtp custom email/sender_name configuration.

avallete commented 23 hours ago

@khera you should now be able to use a custom admin_email and sender_name for your inbucket config by removing those values from your smtp config and placing them under your inbucket config instead like so:

[inbucket]
enabled = true
# Port to use for the email testing server web interface.
port = 54324
# Uncomment to expose additional ports for testing user applications that send emails.
# smtp_port = 54325
# pop3_port = 54326
admin_email = "support@mydomain.com"
sender_name = "MyProject DEV"

Then you should be able to try it out with the latest cli @beta tag like so: npx supabase@beta start.