feat(cli): Add --no-apply flag for db schema declarative sync command

[mittal-parth]

Summary

This change introduces a new flag called no-apply to the db schema declarative sync command , allowing users to generate migration files without applying them to the local database.

Current behavior

$ supabase db schema declarative sync --name test
...
Created new migration at supabase/migrations/20260428093833_test.sql
Apply this migration to local database? [Y/n]

The only escape hatches today:

• --apply — force-applies the migration (opposite of what's wanted)
• Closing stdin via piping, e.g. true | supabase db schema declarative sync ... 2>&1 | cat

Closes#5218

New behavior

• If --no-apply is set, the command writes the migration file and skips the apply step without any prompt
• --no-apply overrides global --yes and cannot be combined with --apply.
• Parity with legacy TS is maintained

[coveralls]

Coverage Report for CI Build 26177550163

Warning

No base build found for commit 72f03fa on develop.
Coverage changes can't be calculated without a base build.
If a base build is processing, this comment will update automatically when it completes.

Coverage: 63.767%

Details

• Patch coverage: No coverable lines changed in this PR.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

Requires a base build to compare against. How to fix this →

---

Coverage Stats

Relevant Lines:	15701
Covered Lines:	10012
Line Coverage:	63.77%
Coverage Strength:	7.06 hits per line

---

💛 - Coveralls

[mittal-parth]

My understanding is that the failing CI / Codegen (pull_request) will get resolved once we merge the deploy branch into this branch?

Or do I need to run a go generate to include those?

[avallete]

My understanding is that the failing CI / Codegen (pull_request) will get resolved once we merge the deploy branch into this branch?

Or do I need to run a go generate to include those?

Your understanding is correct, no action needed on your side 👍