Save image versions to `config.toml` so they can be checked into version control

[haydn]

Is your feature request related to a problem? Please describe.

We've got a team of developers all working on the same project. Some of them have access to our Supabase account and some do not (e.g. front-end developers). We want all of them to run the app in their local dev environment (which is one of the massive benefits of the Supabase CLI — every dev can easily spin-up a local dev environment) and we want all of them to be using the same image versions.

In practice this isn't a huge problem for us because a front-end developer using a slightly out-dated version of Supabase rarely causes any issues, but ideally we to ensure everyone has identical dev environments. I could imagine there are scenarios in other organisations (or ours when we get a little larger) where only limited set of developers have full access to their Supabase project for privacy and security reasons. In a scenario like that it'd be crucial for the back-end developers to all be using the same image versions.

Describe the solution you'd like

When supabase link is run the versions are saved into config.toml so they can be checked in to version control.

@sweatybridge in https://github.com/supabase/cli/issues/1702#issuecomment-1849941331 mentioned a problem with this approach:

We probably don't want to add a config field because it will be difficulty to guarantee newer versions of studio and cli will work the every old version of pgmeta. We don't need to worry about backwards compatibility for temporary files since they are not committed to git and may be deleted anytime.

I feel like this is a problem anyway. As I understand it, the CLI has to be compatible with whatever versions could be copied across via supabase link — which I'm assuming means it has to support some pretty old versions? The problem that probably does need to be avoided is one dependency getting pinned to a specific version while others are automatically updating. A simple constraint could be that authors are forced to specify a versions for everything (including studio) or nothing at all (use the CLI's defaults). I'm imaging the CLI does a check as part of supabase start to see if all the versions have been specified and displays an error if something is missing (could suggest running supabase link to fix the problem).

Describe alternatives you've considered

A workaround would be a custom script which sets the versions in their respective .temp files that is part of a team's setup process. This definitely causes the same problem that @sweatybridge called out above.

Additional context

Related issues:

• 2391

• 1702

[silentworks]

The alternative you described fix this issue as you can check the .temp directory into version control if you wish to have consistency across team. Also you can save your supabase version by installing in into your package.json file as a dev-dependency. The issue of this being outdated would then rely on one member of the team keeping this up to date as you would with anything checked into VC.

I don't think saving the version to config.toml is providing anything better than what I've outlined above as it would be doing the same thing.

[haydn]

Also you can save your supabase version by installing in into your package.json file as a dev-dependency.

👍 Yep, already doing that.

The alternative you described fix this issue as you can check the .temp directory into version control if you wish to have consistency across team.

That sounds a little risky right? The name .temp really implies that it's got files in it that should be considered temporary shouldn't be in version control. Currently, it might only have the image version, but I can imagine a developer working on the CLI in the future would assume that putting anything temporary in there is free game (or change the name/location of existing stuff too).

Like I said, this isn't a huge issue for our team right now, just wanted to get a issue tracked it incase others a googling for a solution too. Happy to have for this to be closed if it's a "won't fix" for now.

[silentworks]

@haydn I just want it to be clear here that I'm not a Supabase staff and what I stated above was my opinion as a independent contributor. I don't think there would be a problem checking in .temp as a workaround for this issue for now.

[sweatybridge]

CLI has to be compatible with whatever versions could be copied across via supabase link — which I'm assuming means it has to support some pretty old versions

Our platform is really supporting only one version (ie. the latest). We don't force users to upgrade but generally encourage users to do so at their earliest convenience. Although cli has to support some pretty old versions, the number of projects running old versions are actually quite few. Pinning versions in config will likely open the doors to more projects running old versions, which I'm hesitant to support.

The problem that probably does need to be avoided is one dependency getting pinned to a specific version while others are automatically updating

I agree there's an inconsistency currently where some service versions are linked but others are not. Eventually, I'd like to get to a point where all local service versions are synced to their linked project.

where only limited set of developers have full access to their Supabase project for privacy and security reasons

For limiting user access, I think it's better to do it via scoped access tokens. Our API team has already started working on this.

I'm imaging the CLI does a check as part of supabase start to see if all the versions have been specified and displays an error if something is missing (could suggest running supabase link to fix the problem).

Yes, currently cli emits a warning if some service version is outdated and suggest to relink. But I think users tend to ignore it.

Perhaps the solution here is to auto update service image versions on supabase start to match those of the hosted project. See https://github.com/supabase/cli/issues/2465

[haydn]

We don't force users to upgrade but generally encourage users to do so at their earliest convenience.

Wait. There's a way I can turn-off auto updating in a project? I've been caught out twice by an update being applied to the live project which causes something to break in a major way. I'd much prefer to be in control of this. Where's the option for this? Is it only for enterprise customers?

For limiting user access, I think it's better to do it via scoped access tokens. Our API team has already started working on this.

👍 This sounds like a good plan.

However, long term, I'd still like to be able to commit the image versions into a repo. If some CI checks pass for a specific commit I wouldn't expect those checks to arbitrarily fail if they're run again at a later date. If the image versions are being pulled via supabase link as part of those CI checks then they 100% could break at any time (e.g. supabase gen types might produce a different result).

You could argue that those tests should fail if they're out-of-sync with the live project. But why is the live project updating first? I'd much prefer to update the versions I'm using in development first, then apply that change to a staging project and last of all apply it to the production project. The other way around makes no sense. (I can't imagine you've got any enterprise customers who'd be happy with y'all just changing the image versions of a production app without testing it first. 😂) If the only way to synchronise image versions is to use supabase link this workflow is just not possible.

Pinning versions in config will likely open the doors to more projects running old versions, which I'm hesitant to support.

It's 100% true that this would be a big anchor, but I think it's inevitable that Supabase will have customers that are on older version that you must support. I totally understand holding off on this for as long as possible, but I can't see how you avoid this long term.