fix: include branches exceeding disk quota

[kevcodez]

Fixes two issues:

• The check for exceeding disk size should only look at relevant projects and ignore projects that are filtered out
• We now include branches that exceed the 8 GB disk, as customers can have long-running / persistent branches

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
studio-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 10, 2024 5:13am

5 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
design-system	⬜️ Ignored (Inspect)	Visit Preview		Dec 10, 2024 5:13am
studio	⬜️ Ignored (Inspect)	Visit Preview		Dec 10, 2024 5:13am
studio-self-hosted	⬜️ Ignored (Inspect)	Visit Preview		Dec 10, 2024 5:13am
docs	⬜️ Skipped (Inspect)			Dec 10, 2024 5:13am
zone-www-dot-com	⬜️ Skipped (Inspect)			Dec 10, 2024 5:13am

[supabase]

This pull request has been ignored for the connected project xguihxuzqibwxjnimxev because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[notion-workspace]

Branches should show up in the disk size overview if they are exceeding free quota

[ecktoteckto]

I'm wondering whether things might be a bit confusing, now that we include branching projects into the list of "relevant projects". I'm talking about lines 162ff. Can the branching project have the same name as the "base" project? If yes, we would list the same project name twice which might be confusing.

Also regarding lines 162ff: Let's say there's a branching project with more than 8GB disk provisioned. If the user sums up the disk size provisioned for the "base" project and the branching project, that would be more than 8GB. On "Compute and Disk" we would show the user that the disk size provisioned is 8GB though, wouldn't we?

[kevcodez]

The branching project's name is <project name> (<branch-name>). Each branch is an entire project with it's own disk, project ref, possibly read replicas, ...

[ecktoteckto]

Thanks for the clarification on the project name. Another question though. What happens if the user clicks the "Manage Disk" button next to a branch project? Does that work with a branch project? (Can't test properly myself right now)

[kevcodez]

Managing Disk for a branch project works, as long as it's a branch hosted on AWS. All new branches are hosted on AWS. I checked the data, we have three Fly-based projects with >8GB disk which would not be able to manage disk, but they can recreate the branch. I think that's a low enough number to not consider this case. We'll eventually migrate those branches over to AWS anyway.

[ecktoteckto]

Couldn't test properly locally/on preview because of GitHub integration. I only faked the Mgmt-API response locally so that the API returns branch projects (with more and less than 8GB disk size)