Skip to content

Conversation

@matlin
Copy link

@matlin matlin commented Oct 27, 2025

What kind of change does this PR introduce?

Feature

What is the current behavior?

Have to seperately deploy changes to migrations, config, and functions.

What is the new behavior?

A single command that will deploy all changes to a remote proejct.

Additional context

  • Adds --remote flag to status to get the health of the remote project.
  • Adds --dry-run support to all deploy commands (added to functions and config)

@matlin matlin requested a review from a team as a code owner October 27, 2025 13:07
Copy link
Contributor

@sweatybridge sweatybridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few high level comments before I dive into the implementation detail.

cmd/deploy.go Outdated
Comment on lines 144 to 153
// What to deploy - use direct Bool() since we check via cmd.Flags().Changed()
cmdFlags.Bool("include-db", true, "Include database migrations (default: true)")
cmdFlags.Bool("include-functions", true, "Include edge functions (default: true)")
cmdFlags.Bool("include-config", true, "Include config.toml settings (default: true)")

// DB push options (from db push command)
cmdFlags.BoolVar(&deployDryRun, "dry-run", false, "Print operations that would be performed without executing them")
cmdFlags.BoolVar(&deployIncludeAll, "include-all", false, "Include all migrations not found on remote history table")
cmdFlags.BoolVar(&deployIncludeRoles, "include-roles", false, "Include custom roles from "+utils.CustomRolesPath)
cmdFlags.BoolVar(&deployIncludeSeed, "include-seed", false, "Include seed data from your config")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm worried that having all these flags would be too overwhelming for the user. Can we show a suggestion to use db specific commands instead? Generally we want to build commands that do one thing and one thing well.

Also from maintenance perspective, we want to very selective about which flag to add. We want to make supabase deploy easy for new users to get started but defer them to specific commands as soon as they need to customise the default behaviour.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've simplified things so you can filter down what you want to deploy with --only=db,config and removed some of those db-specifc flags.

@matlin matlin changed the title feat: Add deploy command to push all changes to remote project feat: add deploy command to push all changes to remote project Oct 29, 2025
@matlin matlin changed the title feat: add deploy command to push all changes to remote project feat: add deploy command to push all changes to linked project Oct 29, 2025
}
}
if !shouldDeploy {
fmt.Fprintln(os.Stderr, "Would deploy:", slug)
Copy link
Contributor

@sweatybridge sweatybridge Oct 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fmt.Fprintln(os.Stderr, "Would deploy:", slug)

Do you mean to log "would not deploy"? We can probably move this log to the keep filter https://github.com/supabase/cli/pull/4368/files#diff-331af3005b73dace93ae60f98283eb774537c9de0399550d705e3dc5c9330ec5R81

return s.upsertFunctions(ctx, functionConfig, filter...)
}

func (s *EdgeRuntimeAPI) upsertFunctions(ctx context.Context, functionConfig config.FunctionConfig, filter ...func(string) bool) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok to undo changes in this file?

if err := api.Deploy(ctx, functionConfig, afero.NewIOFS(fsys), filter...); errors.Is(err, function.ErrNoDeploy) {
fmt.Fprintln(os.Stderr, err)
return nil
return err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were returning nil so that exit code is 0 when there are no changed functions to deploy. What's the reason for changing this?

func init() {
cmdFlags := deployCmd.Flags()

deployCmd.Flags().StringSliceVar(&only, "only", []string{}, "Comma-separated list of components to deploy (e.g., db,storage,functions).")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we intend to use this on CI/CD, I think it's neater to set this via config.toml. For eg. to disable deploying storage

[storage]
enabled = false

For adhoc deployments from local, I'd still prefer directing users to db specific commands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants