Branching - Early access | Feedback discussion

[MildTomato]

This discussion is for tracking feedback and possible issues for Supabase Branching.

This will help us plan a roadmap for the feature going forward.

Vote for hosting provider integrations here and Git providers here.

[bitnom]

This discussion is for tracking feedback and possible issues for Supabase Branching.

This will help us plan a roadmap for the feature going forward.

What is Supabase Branching?

[MildTomato]

In the most concise sense, you can use branching to safely and easily experiment with changes to your Supabase projects.

You can check out the docs here.

[KajSzy]

Is branching expected to be available only from Pro plan or will it be availbe on free tier?
If I decide to upgrade to Pro plan today, will I be able to use branching immediately?

[MildTomato]

@KajSzy We've currently closed the Early Access programme for Branching. If you have already upgraded expecting access, if you could send in a support request and we'll look into it 😄.

I think some of our docs have not been updated to make it clear that it's in private early access, and we've now closed accepting any more requests. I'll update the docs today to be more clear.

[skarard]

Hope you're all doing great! I've been working with supabase on a project for 2 months and noticed something I wanted to share with you that would cause issues for supabase branching. As our projects grow, our seed file (you know, the trusty seed.sql) can become a bit of a beast. We're talking thousands of lines that make you not want to open it up again. In my case, it has ballooned to over 10K lines! Runs pretty fast, sure, but it's a bit of a headache to manage and scroll through.

I've been sidestepping this by ditching the massive seed file and scripting my local database seeding instead. It's a lot like how migrations work: each file is timestamped and has a quick description, and they run in a set order. This means I have separate files for different seeding needs, like permission tables and location table inserts broken down into 1K-insert chunks – it’s pretty neat.

Currently, Supabase runs whatever is in seed.sql and that's that. But here’s a thought: what if branching could also run all the timestamped files we've got in a seeds folder? I think that'd be a game-changer for many of us, making life a bit easier and our projects tidier.

I reckon this could be something worth considering for your roadmap for seeding a branch.

Thanks for all the hard work you've been putting into Supabase, and I'm excited to see how branching evolves!

[MildTomato]

Neat idea.

I also mentioned this to @sweatybridge who is one of the developers managing our migration/seed runner.

I suppose it would have to be timestamped for it to work correctly. Do we know of any other tools doing this? We can't be the first ones to think of this? 😊

[skarard]

To be honest I took the idea directly from my experience of working with the ORM Sequelize. Here is a relevant documentation that mention both migrations and seed files: https://sequelize.org/docs/v6/other-topics/migrations/

One thing to note is that their migrations have an up (which is covered by seed.sql) and a down that is not covered by supabase. The down function is if you are to roll back a migration including any data manipulation that was required to complete the migration. It's very useful when you can't predict how a project will evolve once it's in front of users. Sequelize also handle transactions in their migrations, which makes migrating production databases a lot less intimidating.

[MildTomato]

There is a similar discussion to this here as well now 🙌

[chaos128]

if new branch is created, new Supabase url for client is reserved on new branch??

I maen if I use following url on main branch
const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key')

Can I use a different url for a new branch like staging? For example,
const supabase = createClient('https://xyzcompany.supabase.co/staging', 'public-anon-key')

[MildTomato]

How it works today is a bit like that but it's the id string in the middle that changes.

main branch (production)

const supabase = createClient('https://spztrrugbkgdayfejlvi.supabase.co/', 'public-anon-key')

the feature branch your working on will then have a completely different id in the url

const supabase = createClient('https://qrelykancvxikefwrefd.supabase.co/', 'public-anon-key')

I could understand if this might not be useful in some circumstances, as it makes it harder to build urls based on git branch name in maybe your client or server app.

The problem extends to API keys though as well, since every branch in Supabase has it's own unique set of API keys, db password and so on.

What do you think @chaos128 ?

[chaos128]

It would be okay but I think it would be a little bit inconvenient. It would be better if domain and key are not changed but only pathname is changed based on branch names like I said on question.

main branch
const supabase = createClient('https://xyzcompany.supabase.co/', 'public-anon-key')

staging branch
const supabase = createClient('https://xyzcompany.supabase.co/staging', 'public-anon-key')

feature/test branch
const supabase = createClient('https://xyzcompany.supabase.co/feature/test', 'public-anon-key')

[MildTomato]

That's interesting. Can see that being a lot more useful and easier to use.

Also the keys not changing between Preview Branches is interesting as well - we were mostly concerned with Production and Preview being isolated and concentrated efforts on that and hadn't really investigated on making it easy to switch between Preview branches with predictable URLs and consistent keys. Great suggestion.

[MildTomato]

@chaos128 how are you using Supabase Branching?
are you running your app locally and trying to easily connect to correct Preview Branch?

[rorysaur]

Chiming in here because I would also love to see predictable URLs and consistent keys.

We have a Next.js app on Vercel, using Prisma. Our current workflow, without Supabase branching:

Our branch main syncs to our Vercel staging deployment and uses our Supabase staging db. Our branch production syncs to our Vercel production deployment and uses our Supabase production db. We have a GH action which, upon merge to either of these, runs prisma migrate against the respective db, using creds stored in GH secrets.

That means preview/feature branches create Vercel preview deployments, but have to stay unmigrated (except for staging itself), since we don't want to mess up the staging db before merging to main. So features requiring migrations can't be tested on a preview deployment.

If we turned on Supabase branching on our staging db, I'm picturing that it could work for preview deployments if the app and, separately, the GH action, can both get or construct the branch db's URL/creds (actually we use the full pooler URL) from env variables that are available. And then we'd have the GH action migrate the designated branch db upon branch creation. So a completely new set of URL/creds seems hard to deal with in this scenario, whereas some combination of base URL (already set in Vercel and GH) plus the branch name (already easily available in Vercel and GH) would be very doable.

I see someone else who posted has a similar setup with some steps to make it theoretically work in the GH action.. but it seems to rely on CLI commands, and I'm not sure if that would work for getting the Vercel preview app to also point to the branch db.

(Update: I also just realized Vercel support is in development which would solve the Vercel half.)

[sudonymously]

Can branching be used as a "dev" environment?

[MildTomato]

Yep. What's your use case? Can you tell us more?

[kishanhitk]

According to the docs: "The database is only seeded once, when the preview branch is created. To rerun seeding, delete the preview branch and recreate it."

But when I deleted and recreated the branch (dev), it does not recognise the existing PR from that branch.

[kishanhitk]

EDIT:
The branch migrations are being applied as expected. Only this UI on the dashboard is not being updated properly.

[MildTomato]

That's probably a bug. We are using github webhooks and I think it only adds the PR metadata to the Preview Branch when a PR is opened (there's a webhook event for it) - but that makes it impossible for a new Preview Branch to then be associated with a PR later; like when you've made a new Preview Branch.

I think we could fix that. Everything should work as normal though, it's only the UI here that's been impacted.

[0xBigBoss]

So far pretty good with supabase branching. Should I disable my existing github actions that migrate the production database when merging to the production branch? Is it expected that the migrations should be applied via this new Supabase branching integration?

reference https://supabase.com/docs/guides/platform/branching?making-updates=local-dev#merging-production-changes

[MildTomato]

It's worth stressing first that Branching is not suitable for production based apps right now.

With that in mind, and if you want to continue; yes, you should be able to merge your feature git branch into your 'production' git branch and it will run the new migration files against the Production Supabase branch. There is currently no way to turn this off, so it's probably advised to disable your github actions.

[huyouare]

@MildTomato are there known issues we should watch out for w.r.t. production? Or is it just that more time is needed to bash the bugs out that in theory could harm a prod instance?

[blechatellier]

@MildTomato does supabase branching support monorepos? Our supabase/migrations folder is in a subdirectory (ie: apps/database/supabase/migrations.

[kamilogorek]

Changing a path which /supabase is pulled from is on our roadmap. However as @MildTomato already mentioned, we need to rethink how it works first, to allow multiple Supabase projects to read from a single repo (eg. your monorepo usecase) or any other variant of one-to-many/many-to-many connections.

[tristdrum]

Yeah would love to see this sort of mono-repo support! Very excited for you all to start using branching on internally too!

[donjpierce]

I would also require the mono-repo support for my project with a custom path to my migrations folder. Big fan of this branching feature and how it is progressing!

[kamilogorek]

The code for it is already written and we're going to test everything in upcoming week :)

[kamilogorek]

Monorepo support has been added and is already live if you have an access to branching 🎉

[mosnicholas]

any advice on how to handle issues like this that require setting up things in the database (eg. webhooks)?

[mosnicholas]

@MildTomato -- this is in the CI. We have set up a small webhook, to notify us when new users sign up. When we deployed this to our staging environment, we had to "turn on webhooks" at the DB level, it wasn't automatically on. The same thing is happening with the branching environments.

See here how we resolved the first migration from Local -> Staging. This needs to be automated for branching to work.

[MildTomato]

Ahh I see. If I remember right, when enabling Database Webhooks, this SQL is run - and I assume this is the SQL missing from your migrations.

You are correct, it needs automating correctly.
We should be capturing the schema changes better via the dashboard.

This SQL is also a bit verbose, I wonder wether we should have made an extension for this. I'll ask around internally, there was some ideas on maybe moving all this to a dbdev package as well.

[mosnicholas]

got it -- @MildTomato do I need to add that SQL to my migrations? 😬

[MildTomato]

@mosnicholas - We've discussed some of this internally, and there is now a rough plan on adding Database Webhooks into the initial schema that all Supabase projects (and Preview Branches) are provisioned with. So it would probably be best to not include this SQL in a migration since it will just end up having to be removed and will possibly break when we make changes to the initial Supabase schema.

Perhaps as a short term workaround, we could;

1. Create the Preview Branch - your migrations will fail,
2. Manually 'Enable Database Webhooks' in the dashboard.
3. (Optional) If you don't know the the Database password for the Preview branch - you will need to reset the Database password in the dashboard. This is needed for next step.
4. Then you'll need to remotely run db reset on the Preview Branch by running supabase db reset --db-url "postgres://postgres:[password]@db.[branch-ref].supabase.co:5432/postgres" via the CLI. The [brand-ref] can be seen in the dashboard URL when your looking at your Preview Branch in dashboard.
5. Your migrations should have successfully run now.

We probably need to also make it a lot easier to run db reset while in the dashboard, so you don't need to use the CLI or API to reset it.

The real solution is to make sure Webhooks works for every Supabase project without having to enable it but maybe the above will help unblock you for now.

[mosnicholas]

Thank you!

It's a lot of hassle to run this each time, so I turned off branching for now :) excited for it to be resolved down the line, and I'll use your workaround if I need to make use of branching anytime soon!

[hyldmo]

Hello! Loving the concept so far. After spending some time working around issues (seeding not being run and functions not being deployed), I realised you have a CLI for managing branches (which looks great btw!), and I think it could be highlighted more, as I was under the impression that only the "managed" workflows were supported (i.e only Github + Vercel), but atleast for me the feature set is complete enough that I could run this anywhere (and if i missed that that was possible, many others probably have too)

[sweatybridge]

happy to provide some logs but I was unable to find them

You can find the migration logs by hovering over Supabase status check => Details.

[MildTomato]

Just checking, as we need to improve our documentation:
Did you follow this guide regarding preparing your repo?

[sleakchat]

@hyldmo How did you manage to work around the issue of webhooks not being able to deployed in preview?

I'm experiencing a similar issue, when migrating everything migrates succesfully except for the existing database webhooks:

Connecting to remote database...
Applying migration 20240413231739_remote_schema.sql...
ERROR: schema "supabase_functions" does not exist (SQLSTATE 3F000)                                                                                                                                                                                                              
At statement 80: CREATE TRIGGER "new_kb_topic" AFTER INSERT ON "public"."kb_topics" FOR EACH ROW EXECUTE FUNCTION "supabase_functions"."http_request"('my-url', 'POST', '{}', '{}', '5000')
Try rerunning the command with --debug to troubleshoot the error.

[venku122]

+1 I am also running into this issue.

I went to /database/hooks on the preview branch and enabled webhooks.
Retriggering a deploy did resolve the issue.

[sweatybridge]

My "dream" CI workflow would work something like this:

1. Run supabase branches create $BRANCH_NAME
2. Get project ID from newly created supabase branch
3. Use project ID run regular steps:
4. supabase db push/reset
5. Run codegen off branched supabase instance
6. Run linting / formatting / unit tests
7. Build and deploy frontend with project ID
8. Deploy supabase functions
9. Verify env with E2E tests

If you are willing to manage your own GHA for setting up branches, all of the above are currently available through the terraform provider. We have an example repo here for those who want to tweak and use https://github.com/supabase/supabase-action-example/blob/main/.github/workflows/preview.yaml

I went to /database/hooks on the preview branch and enabled webhooks.

For webhooks, we will look into enabling by default for all new projects and branches.

[DamonGuzman]

We are in dire need of selecting non root directories as the Supabase root. We are using a monorepo with TurboRepo.

[kamilogorek]

It's coming. Bear with us some more time, we're getting there :)

[DamonGuzman]

That's great news! We just finished building our own internal psuedo-branching by creating a new project on every PR. It was quite difficult to implement correctly since there was a silent failure when connecting via IPv4.

Do you have any rough estimation on timelines?

[kamilogorek]

We're hoping to release this month, but I don't want to be held accountable for any specific date just yet.

[kamilogorek]

Monorepo support has been added and is already live if you have an access to branching 🎉

[sidharthv96]

Currently, we're testing each branch by setting up a local supabase instance in GH Actions for every run. But that setup takes a significant amount of time compared to the actual test run.
So we're looking for a way to accelerate the setup process, using branching.
We have our seeding script in TS, and are using Prisma for migrations, and use Vercel for deployment.

The flow that we have in mind is:

1. Inside GH Actions, on PRs
2. List all branches using supabase CLI
3. Create preview branch if required
4. Get the details of the preview branch using CLI (URL, API key, etc.)
5. Update our .env file with the details, clear, migrate and seed the database (to be consistent across runs)
6. Run the tests
7. When PR is merged, use supabase CLI to delete the preview branch

Are there any blockers that we should be aware of?
Is there a better way to do this?

Moreover, once this is set up and the Vercel app is used, I'm assuming the preview instances will use the new branched supabase.

We also don't want any changes in the preview branches going back into main (which I assume will not happen as we are not using supabase migrations in the preview branches). Can you please confirm this?

[sweatybridge]

which I assume will not happen as we are not using supabase migrations in the preview branches

Yes that is correct. The Supabase GitHub integration only look for files in supabase/migrations directory. If it is empty, no migrations will be run.

Overall your approach sounds sane to me.

We will need to make some changes for step 2 and 3 so that you can fetch a preview branch by its git branch name. Otherwise the current workaround is to parse the output from branches list command to extract the branch id. Then use pass the branch id to branches get command.

You might also need to handle retries in step 4 until the status of your branch database is ACTIVE_HEALTHY.

I think step 7 is not required if you use the Supabase GitHub integration. Because we delete the branch on PR close.

[thedevdavid]

Feedback/idea: It'd be nice (or even crucial) for the preview branch to copy most local and/or production branch settings.

Examples:

• custom email templates (because you need to customize them for Next.js SSR)
• use the production API endpoint with a subdomain or route for preview branches
• auth site & redirect URLs
• auth provider settings
• project auth settings (custom SMTP included)
• upload size limit
• edge function secrets (or at least some prompt to set them)

[ronthedrummer]

I'd love the option to make that a setting in the branching settings. I needed to make a change to my auth OTP email template recently and having the option to copy the production version over to my dev branch and test would be nice. Eventually I'd like to see the auth email templates maintained in code (/supabase/emails/confirm-signup.mjml)

[Tananga]

This is a must have

[MarkBennett]

Given the branching is meant to correspond with git branches, perhaps moving all these settings into the supabase folder and then letting you change them in the filesystem would make sense?

That would let teams modify using their existing git workflow, and handle these decisions there?

[sweatybridge]

perhaps moving all these settings into the supabase folder and then letting you change them in the filesystem would make sense?

This sounds like a configuration as code proposal. We have a terraform provider example where all the auth and api settings are committed to git. https://github.com/supabase/supabase-action-example/blob/main/supabase/remotes/preview.tf

In the long run, we probably want to support copying configurations from base project so that we don't explicitly depend on terraform in the infrastructure.

[ronthedrummer]

For some reason I'm not seeing migrations running or seed data populated for a preview branch (feature or development). When I create a PR, it's spinning up the branch, just no tables or seed data.

[kamilogorek]

When creating a new branch on Github, it doesn't mean I want to create a new branch on Supabase automatically. Only when there are changes in the ./migrations folder I'd say. Or make that arbitrary.

Done, you can use it today.

Option to have the data populated in an easy way

There is basic seeding capability already with seed.sql file, but we want to add better integration with Snaplet or similar tool as well in the future.

[morasaek]

Whenever I merge branches, the branch disappears. I think this might be useful when working with feats, but when you want a permananent staging branch, it's not desired.

+1(00) on this point!

[RobSchilderr]

They say the best way now is to create a separate Supabase project for the staging branch.

[kamilogorek]

Q: We have few ideas how to go around it, but just to get a feel for it in public, wdyt is your preference in regards to long-lived branches?

• hand-pick already existing branches to be persisted, eg. on branches page - https://supabase.com/dashboard/project/_/branches
• change the setting to be applied for a whole connection on - https://supabase.com/dashboard/project/_/settings/integrations
• have a connection setting where you can list branch names to be persisted
• other approach?

[huyouare]

Adding a data point: we are using a separate project for Staging + Preview branches, while keeping our original project for Production only (same as @RobSchilderr's post above). This seems to work pretty well for persisting Staging so far, though it's not 1:1 with the Vercel style of branching.

[amitav13]

We handle our migrations via Prisma migrate. Are there any plans to support the migrations folder generated by this? Or any workarounds at this point?

[kamilogorek]

Currently you'd have to move file to migrations directory inside ./supabase, but that's a good improvement for the future. Thanks

[amitav13]

Would just moving the folder work? The migration files/formats are directly compatible with supabase?

[kamilogorek]

Yes, the migration file is always just a smallest sql snippet that will result in the desired schema shape at the end of execution.
They are usually tracked via sorted list of migration files, that are stored in _migrations (or similar) table.
The only difference here is that prisma expects migration files path to be migrations/data_name/migration.sql file, eg migrations/20210313140442_init/migration.sql, where Supabase expects migrations/20210313140442_init.sql, which means that you'd have to do something like code below to copy, rename and put them in correct place in one go.

find . -type d -depth 1 | xargs -I{} cp {}/migration.sql migrations/{}.sql;

[amitav13]

Got it. A cleaner way built in to supabase would be nice! Especially since there's a pretty large audience (I'm assuming) of supabase TS users using prisma.

[UmashankarSpeckyfox]

Hey Folks

I want to Setup a Supa Base Branching for the Automation Testing so the scenario is Below
I need to Setup the CI/CD pipeline for the Automation Project. Pipeline is already exists but i need to run my tests in between build and Deploy. So i want to use a Supabase branching to run my automation scripts on supabase temporary branch.

So how i can do it can anyone help me out in this

Thanks in Advance.

[nkmnz]

Great feature! I'm using Cloudflare pages and enjoy their automatic deployment of my frontend app. Is there a way to automatically retrieve the connection string of a branch so that I could pass it to the build of the frontend application? Alternatively (and much preferred), might it be possible to configure connection data via code or repository secrets?

[nkmnz]

@0xBigBoss just saw your posting about https://github.com/0xBigBoss/supabase-branch-gh-action
Looks nice, thanks! Seems like I need to replace cloudflare's github app with another stage that I add after your action, right?

[0xBigBoss]

hey @nkmnz not sure how you are deploying to cloudflare pages but that sounds mostly correct. You can see how we're doing it here and configuring vercel. https://github.com/0xsend/sendapp/blob/dev/.github/workflows/ci.yml#L247-L252

[nkmnz]

So far, I've configured the cloudflare github app via the cloudflare interface, so there's no github action. I'd like to keep it that way since it provides some stuff out-of-the-box that just works. I'm now thinking about using the supabase cli with supabase branches get UUID to retrieve the database branch info while building the frontend – but the CLI's output is a very arcane table, no json output available. Any chance json output could be enabled with the -o json flag like it is done for other cli commands, @kamilogorek ?

[0xBigBoss]

I think there are still other things missing from that branch output which is why I didn't just use that in the github action. I think things like service role and jwt key.

You can prob copy paste this script and remove the github action stuff. It uses the Supabase Manager API https://github.com/0xBigBoss/supabase-branch-gh-action/blob/master/src/index.ts#L92

Or you can just leverage the Supabase manager API directly or use my typescript library, https://github.com/0xBigBoss/supabase-manager-js

[nkmnz]

Thank you very much, @0xBigBoss – I've ended up using supabase-manager-js, works like a charme!

[Tananga]

Hello. Since last week Supabase branching is public so Im able to test this feature and here is my feedback:

I watched https://youtu.be/peXKxavGnBo?si=RnJ6OtjpnbZRmYEk and I really cant understand why Jon created feature directly from "production" branch. For TODO app which no-one gonna use its ok but in real life your always wanna create "main", "qa", "dev" branches on git. Take a look on photo:

I dont understand why do I need to create 3 separate projects for PROD, QA and DEV and not just one with 3 permanent branches inside + one more temporary branch per feature. I also dont understand pricing: If I would like to create this one project with dev branch, qa branch and prod branch why do I need to pay 0.33$ per day per branch if separate project is free? Maybe Im not as experienced as you guys but I have a hard time with this.

[kamilogorek]

You should check your "Branches Overview" table now :)

[RobSchilderr]

You should check your "Branches Overview" table now :)

That's nice!

[Tananga]

@kamilogorek Love to see that our opinion matters for you guys❤️ Pricing for branches are still the same? It starts to be a little expensive: 25$ for pro plan + 1$ per day for 2 pernament branches like DEV and QA and 1 temporary feature branch its 55$ per month... its hurts a little

[tomx-sh]

I'm not an experienced dev so I'm not familiar with CI/CD pipelines and what is common practice in the industry. Sorry if the following sounds extremely novice.
On second thought, a workflow with temporary branches kinda makes sense to me now.

1. We really only need a test supabase environment when there are changes (new migration files). When there are no changes, it makes sense to connect our preview directly to the prod environment, doesn't it ? We can have admin/test accounts there.

2. We could accommodate to the fact that the test environments only live for as long as the PR lives. We have to see the PR as the beginning of the testing process, not the end. Like "these changes work locally, here is a draft PR, let's test together if it works on a deployed env". When we're done, PR is closed, test env is disposed. Why would it be permanent ?

This branching feature could allow for innovative workflows, I would love for the supabase team to publish guides for newbies like me !

[kamilogorek]

@Tananga for now it's the same, as we have to spin-up a new machine for each, but we'll definitely try to improve it in the future base on the most common use-cases.

Sorry if the following sounds extremely novice.

All questions are valid :)

When there are no changes, it makes sense to connect our preview directly to the prod environment, doesn't it ?

Correct, however if there are no changes to migrations, we will not create a branch for you, so you will not be charged anyway. It'll be skipped.

When we're done, PR is closed, test env is disposed. Why would it be permanent ?

You are correct. It's not a very useful feature in most setups, but there are some valid scenarios where you can use it:

• have a long-running branch, which will still be there after merging a PR, will allow you to reuse the same seed data in case you want to test how it behaves in different envs. (eg. dev, staging, canary)
• spawning a new branch will in the future carry over all configuration of the parent project (we still have some work to do here)
• it's simply very fast
• when you use something like Vercel with Preview Deploys, you still want to be able to visit your Preview Deploy after merging the PR in specific cases (eg. sending a preview update to your client)

[jesse-a-reilly]

I'm having trouble getting started with branching. I've successfully enabled branching, but when I try to create my first branch, I receive a Migration Failed message:

Looking at the Github Check log, it appears Supabase is trying to apply a migration that's already been committed to the master branch:

Connecting to remote database...
Applying migration 20240328023519_remote_schema.sql...
Applying migration 20240328023521_remote_schema.sql...
ERROR: relation "sa1_2021_to_sal_2021" already exists (SQLSTATE 42P07)     

I've checked my migration files for duplicate CREATE statements, and I've checked that all of my migrations have been merged to the master branch. All local migrations appear to be in sync with my production DB:

$ supabase migration list        
Connecting to remote database...

  
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
    20240328023507 │ 20240328023507 │ 2024-03-28 02:35:07
    20240328023509 │ 20240328023509 │ 2024-03-28 02:35:09
    20240328023511 │ 20240328023511 │ 2024-03-28 02:35:11
    20240328023513 │ 20240328023513 │ 2024-03-28 02:35:13
    20240328023515 │ 20240328023515 │ 2024-03-28 02:35:15
    20240328023517 │ 20240328023517 │ 2024-03-28 02:35:17
    20240328023519 │ 20240328023519 │ 2024-03-28 02:35:19
    20240328023521 │ 20240328023521 │ 2024-03-28 02:35:21
    20240328023523 │ 20240328023523 │ 2024-03-28 02:35:23
    20240328023525 │ 20240328023525 │ 2024-03-28 02:35:25
    20240328023527 │ 20240328023527 │ 2024-03-28 02:35:27

What's the best way to troubleshoot this issue?

[fred-transitiv]

I'm having the same issue.

I don't see where you're even getting the logs. I just get migration failed.

My only migration script is the file the CLI generated from pull.

[kamilogorek]

@jesse-a-reilly can you give it a try now? We fixed one issue in regards to applying migrations last week, which should handle your case.

[tristdrum]

Hey @MildTomato & @kamilogorek !

So pumped about public availability! Congrats! Loving the innovation & listening (I'm watching from the background most of the time). I'm waiting with baited breath to get my whole stack across to branching the moment it's production ready!

In the announcement above, it was said:

We still have many features to add to branching before 1.0, so please continue sending us your feedback!

Can you give us some insight into what the "many features" are please?

[kamilogorek]

Hmm, to name a few from the top of my head:

• Custom project configuration + inheritance from the parent project (most likely via supabase/config.toml file
• Allow for accounts filtering (eg. only specific team should be able to spawn branches in PRs)
• Trigger only on changes to specific files/labels
• Support for other vendors (right now it's integrated with GitHub, but you can write any workflow yourself using CLI)
• Automated data seeding with either built-in scripts, or our partners like Snaplet
• Better story around Vercel deployments (right now there are few kinks that we need to iron out)

[gmjosund]

Hey, maybe i have missed something, but each time i updated my persistent branches i need to re-enable the social auth providers. They appear switched on/enabled but i am getting this error in frontend:
{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

If I turn the provider off/on again its working, just a bit of a pain to do that each time.

[sweatybridge]

By updating persistent branches do you mean simply doing a git push to the associated git branch?

Could you also provide a screenshot of the frontend error? It's not clear to me if the dashboard is showing that provider is not enabled or if the error is throw from auth client library.

[gmjosund]

By updating persistent branches do you mean simply doing a git push to the associated git branch? YES

So lets say i have updated the alpha branch, then i would get this in frontend:
{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

Provider is enabled, but if i disable and then enable again its working.

[sweatybridge]

Thanks for clarifying. We have successfully identified the issue. We will most likely release a fix tomorrow.

[geoguide]

Can I get help understanding branching and how to use it? It seems to me that when I move to a branching workflow I'm moving all of my editing work to my local environment which makes all of the hosted UI not useful anymore. I really enjoy the help that the supabase pro ui gives me but if i'm just doing all the postgres stuff locally i'm not really getting any of that benefit anymore. Is there something I'm missing?

What I am currently imagining is that i can go into my "dev" supabase branch on the dashboard and make edits there that I can migrate into main, but that does not appear to be how it works at all. I still have to do all the changes in the local and then it gets pushed to the supabase branch so the UI tools are removed from my workflow.

Edit: Looks like I might be able to just pull from a persistant dev branch using db pull after I make changes in the UI but then i'm not going to get the migrations run on main ever unless I manually run them? I think I'm getting confused about the dev DB vs the dev db branch. It'd be cool if i could edit the dev db in the UI and then apply the migrations to the branch and have it take care of merging those changes to main so that my migrations applied with the code but were created from my editing on supabase.com

And the only way to pull the data to seed dev is to do it locally and so i would also need to push from local to dev? 🤔

I know there's a lot going on in this post I'll try to rewrite it after i clean up what I did 😆

[Tananga]

Im waiting 18 minutes for Supabase Github extension is it normal?

[Tananga]

35 minutes. I really dont know what to do right now

[Tananga]

Its 1 hour and its still going. Can I cancel it manually?

[kamilogorek]

The issue should be fixed now, sorry for inconvenience.

[felipe31]

It seems there is some unexpected interaction between branches and the Vercel integration.
I have both set up and whenever I try to create a preview branch manually or automatically, I get the following error.

{
   "error":{
      "code":"BAD_REQUEST",
      "message":"Branch ""my-branch"" not found in the connected Git repository.",
      "key":"gitBranch",
      "envVarKey":"POSTGRES_URL",
      "gitBranch":"my-branch"
   },
   "failed":[
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_URL",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_PRISMA_URL",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_URL_NON_POOLING",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_USER",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_HOST",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_PASSWORD",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"POSTGRES_DATABASE",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"SUPABASE_ANON_KEY",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"SUPABASE_URL",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"SUPABASE_SERVICE_ROLE_KEY",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"SUPABASE_JWT_SECRET",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"NEXT_PUBLIC_SUPABASE_ANON_KEY",
            "gitBranch":"my-branch"
         }
      },
      {
         "error":{
            "code":"BAD_REQUEST",
            "message":"Branch ""my-branch"" not found in the connected Git repository.",
            "key":"gitBranch",
            "envVarKey":"NEXT_PUBLIC_SUPABASE_URL",
            "gitBranch":"my-branch"
         }
      }
   ]
}

To work around this, I need to delete Vercel's integration.
I searched the docs and I could not find any configuration to solve this. Am I missing something?

[sweatybridge]

Thanks for reporting this issue. It was caused by vercel project not connected to git repo. But it should not fail branch creation. We have fixed it in our platform as of today.

[huyouare]

Is there a way to set the JWT secret programmatically for branches? I'm using the Clerk Supabase integration, which requires that the JWT secret matches between the Supabase instance and Clerk. However, each branch in Supabase has its own JWT secret, which seems to only be set manually. Ideally, the JWT secret would be copied from the base ("production") settings.

[sweatybridge]

Sharing JWT secret between prod and branches would be a security risk. Does Clerk support setting JWT secret via api, and separately for each branch project? That would be probably be easier to start.

Otherwise, we can look into configuring custom JWT secret instead of only supporting JWT rotation.

[huyouare]

Does Clerk support setting JWT secret via api, and separately for each branch project?

Clerk isn't set up for branching, so we have just one instance that's shared for development. Setting custom JWT secret (or having it fixed between branches) would be great.

Sharing JWT secret between prod and branches would be a security risk.

We use the base/"production" branch as staging in a separate project (and production is its own project) as suggested in an earlier post.

[trevorpfiz]

Wondering what the best way to use Supabase + Drizzle with branching is? Should I be using the Drizzle migrations? https://twitter.com/plushdohn/status/1780126181490135371

[tobico]

The concept of branching seems very promising, but I'm not sure where the front-end side of things fits in. If Supabase spins up a new back-end for a PR at a different address, that's only a partial solution and we can't actually test our app without a corresponding front-end being deployed.

I think the component that's missing is some kind of API with a corresponding GitHub action that can be used to retrieve the details of the branch Supabase server which would then be used by our custom deploy scripts to launch a branch-specific version of the front-end.

[kamilogorek]

I think the component that's missing is some kind of API with a corresponding GitHub action that can be used to retrieve the details of the branch Supabase server which would then be used by our custom deploy scripts to launch a branch-specific version of the front-end.

There is community based solution for GH actions to do that here:

• Step 1: wait for Supabase check https://github.com/supabase/supabase/blob/master/.github/workflows/config-preview.yaml#L16
• Step 2: fetch branch details https://github.com/0xBigBoss/supabase-branch-gh-action/tree/master

We are also working on providing Webhooks for our OAuth integrations to make this easier to work with.

[leoweebt]

I'm receiving a "Migration failed" in my preview branch.

I create the main branch, ran the subabase init and created the schema.

[kamilogorek]

You should be able to see all the details about what happened in your GitHub PR action details.

[hami-sh]

Hey there! Love Supabase, appreciate all your work.

Trying to set up a preview branch. Unfortunately, getting an error:

Connecting to remote database...
Do you want to push these migrations to the remote database?
 • 20240408065334_remote_schema.sql
 • 20240409104957_remote_schema.sql

 [Y/n] 
Applying migration 20240408065334_remote_schema.sql...
ERROR: PostGIS installation stopped: pgaudit.log is set to 'ddl'. Set pgaudit.log to 'none' before installing PostGIS. You may re-enable pgaudit after installation is complete. (SQLSTATE P0001)
At statement 0: create extension if not exists "postgis" with schema "extensions"                                                                                                                
Try rerunning the command with --debug to troubleshoot the error.

Clearly the postgis extension is not playing ball. Can I have some help please?

[blechatellier]

Hey, I've manually created a branch and it has been stuck on "Running migrations" for the last 10 minutes. Database is healthy, I can see all the migrations in the list.

My seed file is fairly large, about 15,000 rows. I've removed my seed.sql and it goes through. It also goes through if I reduce the number of rows.

Is there a limit for the size of the seed.sql? If I try the same query in the editor I get a payload too large error, could this be happening when the branch tries to setup the seed?

[dccakes]

We have been testing branching with vercel deployments for a bit. Some feedback:

1. We are noticing issues with the synching of env vars - sometimes the branch is created but the envs are not synched.
2. Once branches are deleted - the env vars are not being deleted from vercel, but the branch is deleted from supabase. Having more automatic e2e would be good. i.e. branch is destroyed in GH -> db destroyed in supabase -> envs removed from vercel.