Local dev with env() in config.toml file - version control best practice

[xmliszt]

Hi all, my question is regarding the version control for config.toml file when we set up supabase for local development. More specifically, this file is not ignored in the .gitignore by default so I guess it is meant to be pushed to the repository? However, I have a problem with it once it is pushed up.

I have github actions set up to automatically deploy supabase changes to preview and production DB. So when config.toml is pushed to repository, its changes will be visible to the Github actions. However, in my case, I have set up Google OAUTH for my app so I have put env(SUPABASE_GOOGLE_OAUTH_CLIENT_ID) and env(SUPABASE_GOOGLE_OAUTH_CLIENT_SECRET) inside the config.toml file, which are only meant to be visible when running locally in my computer. So I put those env variables inside .env file as instructed in supabase official site. However, since config.toml is pushed, when my preview or production pipeline try to run the supabase deployment flow, e.g. supabase db push, it will try to read this config.toml for some reason and tells me that the env(SUPABASE_GOOGLE_OAUTH_CLIENT_ID) cannot be resolved, because I didn't set them up (obviously) in the github workflow environment.

But the point is, these env variables are meant for local only, so I don't want to add them into the github actions secret. Then how should I do it properly? Does anyone encounter this before and what's your solution or workaround for this? I'm excited to learn how yall do it and learn from the best practice.

In my case, my current workaround is kind of hacky, I use Husky to run a pre-commit hook that unstaged the committed config.toml whenever it gets staged for a commit. So that its changes containing those env() will never get pushed...

[steezeburger]

I too need to know about the proper workflow for supabase, but just wanted to mention that you don't need a husky pre commit hook for your hacky workaround. Git has skip-worktree for this use case.

https://stackoverflow.com/questions/13630849/git-difference-between-assume-unchanged-and-skip-worktree

[xmliszt]

Thanks for bringing my attention back to this long forgotten discussion! Supabase has updated the doc and my request here should be considered resolved: https://supabase.com/docs/guides/deployment/branching/configuration#managing-secrets-for-branches

By using encrypted values, we can commit the encrypted values env files to github and Supabase will decrypt it in the workflow using edge functions.