search

supabase / cli

Supabase CLI. Manage postgres migrations, run Supabase locally, deploy edge functions. Postgres backups. Generating types from your database schema.
https://supabase.com/docs/reference/cli/about
MIT License
1.07k stars 209 forks source link

The default answer for `supabase db reset --linked` should not be `Y` #1875

Closed DanEEStar closed 6 months ago

DanEEStar commented 9 months ago

Is your feature request related to a problem? Please describe. I used the command supabase db reset --linked for the first time. I was suprised that the default answer is "Yes". In my opinion it should be "No" to at least prevent the reset when I accidently run the command and just pressed "enter".

Describe the solution you'd like The line 54 in reset.go

if shouldReset := utils.PromptYesNo("Confirm resetting the remote database?", true, os.Stdin); !shouldReset {

sould become 

if shouldReset := utils.PromptYesNo("Confirm resetting the remote database?", false, os.Stdin); !shouldReset {

Describe alternatives you've considered No alternative

sweatybridge commented 9 months ago

Hmm I initially thought it's ok to default to Y because user passing in --linked flag is already expressing explicit intent to reset the remote database. And we are just confirming again.

But I'm happy to change it to your suggestion if it's safer to prevent accidental key press.

Also considering the behaviour on non-interactive consoles, we might want another flag --force to skip the promptly entirely.

Ninjeneer commented 7 months ago

I totally agree with this one, destructive actions should never be authorized by default

tobiastornros commented 6 months ago

Any plans to add --force or --yes to this command @sweatybridge? Trying to use it in github action to reset staging every night.

sweatybridge commented 6 months ago

You can pipe yes / no to cli via stdin. For eg.

yes | supabase db reset --linked
tmountain commented 6 months ago

We're piping yes now, but it does seem like a command-line arg is the right way. Also, this bit us out of the blue (staging environment broke on rebuild). Is there a better way to roll out breaking changes to core tools? Changing a command so that it runs interactively can definitely impact your users.

sweatybridge commented 6 months ago

Is there a better way to roll out breaking changes to core tools?

Perhaps the CLI can print the suggested replacement command on such breaking changes in the future. So at least it's more straightforward to fix any broken builds.

In this case, we had to fix it sooner than later to prevent more users from accidentally deleting prod data.

hnykda commented 5 months ago

I made it into a new feature request: https://github.com/supabase/cli/issues/2341