cli: Config.toml env variable replacement fails

Bug report

Describe the bug

When trying to run supabase start/stop using CLI versions 0.21.0 or above, an error is shown if an env variable is used in the config.toml. This used to work with 0.18.2.

❯ source .env && supabase stop
Error: Error evaluating "env(GITHUB_CLIENT_ID)": environment variable GITHUB_CLIENT_ID is unset.
❯ echo $GITHUB_CLIENT_ID
some-client-id

Config

# other sections omitted
[auth.external.github]
enabled = true
client_id = "env(GITHUB_CLIENT_ID)"
secret = "env(GITHUB_SECRET)"

Let me know if more details are necessary. Thanks!

To Reproduce

Add the above config snippet to a Supabase project
Create a .env file with GITHUB_CLIENT_ID=foo as contents
run source .env && supabase start
See error

Expected behavior

The env variables should be interpolated into the config.toml. Ideally:

misconfigurations in the TOML file shouldn’t prevent stopping the local Docker containers
env variable substitution should work throughout the config, and not just for auth providers

System information

OS: macOS 12.3
Version of supabase-cli: v0.22.4
Version of Node.js: v16.13.0

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 16 (12 by maintainers)

Most upvoted comments

I think you might need to use export GITHUB_CLIENT_ID=a etc. in your .env - ~source runs the script in a subshell so the envars are not passed to the supabase command.~

I’m not sure how/why it used to work though.

Edit: setting the variable only makes it available in the current shell, not to subcommands - echo worked because the substitution happens in the current shell. So you’d need to export it.

soedirgo on Mar 30, 2022

Thanks for the report! Will try to reproduce this.

soedirgo on Mar 30, 2022

I think you might need to use export GITHUB_CLIENT_ID=a etc. in your .env - source runs the script in a subshell so the envars are not passed to the supabase command.

I’m not sure how/why it used to work though.

Before I didn’t even need to run source. I would just alias my root /.env file to /supabase/.env. That seemed to work as intended. And just to confirm, the env variables aren’t loaded in automatically if I omit the source command either.

Issue with having to put export ... is that this then breaks the dotenv format and breaks usage with other tools.

I liked the aliasing workflow as it meant that we didn’t have to juggle two sets of configs, and less chances of errors/accidental VCS commits.

I’ll see if I can find a workaround, or have to adapt our workflow.

Thanks for investigating 🙏

alex-ketch on Mar 30, 2022