What is the correct way to handle config.toml when running the CLI in Github Actions

[IPJT]

Hi,

I'm setting up a CD-pipeline in Github actions to deploy to production using supabase db push.

When doing so the cli picks up the config.toml which causes some error as it has been setup to be used for the local environment. Any ideas how to handle this?

Thank you!

[IPJT]

Clarification:
In order to run the send email auth hook during local development i have the below settings in my config.toml:

[auth.hook.send_email]
enabled = true
uri = "http://host.docker.internal:3000/api/auth/email-webhook" #host.docker.internal is a special DNS name used in Docker to allow a container to access the host machine's network. This allows the Auth container to reach the route handler
secrets = "env(SUPABASE_SEND_EMAIL_HOOK_SECRET)"

This works perfectly fine and does exactly what i want it to do when running the Supabase stack on my local machine. The SUPABASE_SEND_EMAIL_HOOK_SECRET-secret is in my .env file which is not tracked by git. So far so good.

The problem:
In my CD-pipeline (deploy-production.yml) I do:

  - name: Setup Supabase CLI
    uses: supabase/setup-cli@v1
    with:
      version: latest

  - name: Link with Supabase
    run: supabase link --project-ref ${{ env.SUPABASE_PROJECT_ID }}

  - name: Deploy Supabase migrations
    id: deploy-db
    run: |
      echo "Starting database migrations..."
      cd apps/api
      if supabase db push; then
        echo "Database migrations completed successfully"
        echo "db_success=true" >> $GITHUB_OUTPUT
      else
        echo "Database migrations failed"
        echo "db_success=false" >> $GITHUB_OUTPUT
        exit 1
      fi

The pipeline will fail with the following message:
WARN: environment variable is unset: SUPABASE_SEND_EMAIL_HOOK_SECRET Invalid hook config: auth.hook.send_email.secrets must be formatted as "v1,whsec_<base64_encoded_secret>" with a minimum length of 32 characters.

The explanation:
This is due to the cli in the pipeline having access to the config.toml file but not the .env file where the secret is defined.
When running supabase db push it only runs the migrations and shouldn't touch hooks config. However, I guess the CLI will validate the whole config file which causes the error. With that said, I guess I could work around it by overwriting the checked in config.toml file in my CD-pipeline with a temporary minimal file (could prob be empty).

However, I kind of don't like the idea of this. It feels like there must be a better way of handling this. Seems dangerous that the production CD tries to read the configs from my file for local environment config even though I assume it wouldn't use it.

I hope this clarified things. Thank you for wanting to help!

[IPJT]

For anyone else finding this in the future:

The CLI (regardless of being run locally or in a CD-pipeline) requires a config.toml-file. It also validates the content (hence the error). This is true regardless of the CI-command you're running needs any configuration (supabase db push doesn't).

You basically have 3 options.

Option 1 -
In your CD-pipeline just programatically overwrite your checked in config.toml with a config.toml that will pass validation (I think an empty one will do).

Option 2 -
Declare the SUPABASE_SEND_EMAIL_HOOK_SECRET as a secret in Github and pick it up in your .yml-file :
env:
SUPABASE_SEND_EMAIL_HOOK_SECRET: ${{ secrets. SUPABASE_SEND_EMAIL_HOOK_SECRET }}

The config.toml file will now be valid and will pass validation
I don't like this approach as the secret is actually not used and might cause confusion

Option 3 -
Use the config.toml file not only for you local environment but also for all your other Supabase environments.
In your CD-pipeline you can run supabase config push which will update your remote project with the configurations in your config.toml.
See this blog-post from Supabase on how to overwrite certain settings for certain supabase environments (works for both branching and seperate projects).
This means you wouldn't put the SUPABASE_SEND_EMAIL_HOOK_SECRET in the Supabase platform manually (for prod) but instead declare it as a secret in Github to be picked up by the workflow.

I hope that helped!

[muezz]

I am having the exact same issue with the exact same env variable coincidentally. I wanted to ask and see if maybe you found a cleaner way to handle this situation.

For some context, I am using the official Supabase branching feature. In that feature, there is an integration of your github repo in your Supabase project. There is an GH action, from Supabase, that runs automatically on each commit.

Option 1 - I don't have access to this GH action and am unable to create an empty config file. And I am not a fan of doing this as this will make it harder for me to catch genuine mistakes, I think.

Option 2 - I tried this but I think the GH action does not pick up the env variable automatically. And since I dont have access to the action, I can't do it manually. I also do not like having my env variables in multiple places. I prefer a singular source of truth.

Option 3 - Same issue as before. I can't edit the official GH action from Supabase.

Do you have any suggestions? I am blocked because of this and can't find any useful resources in the docs.

[IPJT]

Hey,
Sorry for the late response.. Haven't "figured out" notifications in Github yet...
I went with option 3, but I don't use the branching feature, so I see why this doesn't work for you.

The reason I didn't go with the branching feature is because I want full control, e.g. in situations like these.

Hope you figure(d) it out!