feat(deploy): report whether a deploy created or updated an application

[gu-stav]

Description

A sanity deploy with no deployment.appId succeeds without prompting — good for humans and agents — but the output never said it had created a brand-new application. So re-running the deploy silently created duplicate apps, and there was no machine-readable signal of what happened.

This keeps the no-input behaviour and only adds feedback: the success output now states created vs updated, warns (on a no-appId create) that the next deploy makes another app, and the resolved target carries action: 'create' | 'update' for --dry-run/--json. No existing human-facing copy changed.

How it worked before (where it broke)

sanity deploy  (workbench app, or plain coreApp)
  |
  deployment.appId set?
  |
  +-- yes --> UPDATE that app
  |             "Success! Application deployed to <url>"
  |
  +-- no  --> CREATE a new app  (no prompt)
                "Success! Application deployed to <url>"      <- same line as update
                "Next step: Add the deployment.appId ..."     <- hint, but no reason given
                |
                re-run without appId --> CREATE another new app   <- silent duplicates

The success line was identical for create and update, the appId hint never said why it mattered, and --json carried no create/update field — so neither a human nor an agent could tell a new app had just been made.

After this PR (added output, same flow)

sanity deploy
  |
  deployment.appId set?
  |
  +-- yes --> UPDATE
  |             "Success! Application deployed to <url>"
  |             "Updated the existing application."
  |
  +-- no  --> CREATE new app  (still no prompt)
                "Success! Application deployed to <url>"
                "Created a new application."
                Next step:
                  "Deploying again without deployment.appId
                   creates another new application."
                  + the appId snippet to pin this app

dry-run / --json (both paths):
  target.action = "create" | "update"

What to review

• logAppDeployed in deployApp.ts — the added created/updated line and the redeploy warning (only when it created without a configured appId).
• DeployTarget.action in deployChecks.ts and every target construction (deployApp.ts, deployStudio.ts, the describe*Target verdicts) — derived from whether an existing app was resolved (update) or a new one made (create). No message copy was changed.

Testing

logAppDeployed unit tests assert both the created (with redeploy warning + appId snippet) and updated output; describeAppTarget/describeStudioTarget unit tests assert target.action for create and update on the app, studio, and workbench paths. Integration deploy tests still pass.

---

Note

Low Risk
Additive CLI messaging and JSON fields only; deploy resolution logic is extended with explicit create/update tracking, not rewritten.

Overview
Deploy feedback now distinguishes create vs update without changing deploy behavior when deployment.appId is missing.

After a successful core app deploy, the CLI prints "Created a new application." or "Updated the existing application." On a create with no configured appId, it adds a yellow warning that another deploy without deployment.appId will create a duplicate, alongside the existing appId snippet.

DeployTarget gains action: 'create' | 'update', set in dry-run checks (describeAppTarget / describeStudioTarget) and in real deploy JSON for apps, studios, and workbench paths. Resolution helpers (resolveAppApplication, resolveStudioApplication, findUserApplicationForStudio) now return a created flag so post-deploy target.action matches what actually happened (including registering a configured-but-unregistered studio host as create).

^{Reviewed by Cursor Bugbot for commit 140b39c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gu-stav]

This change is part of the following stack:

• feat(deploy): report whether a deploy created or updated an application #1462 ◀

_{Change managed by git-spice.}

[github-actions]

📦 Bundle Stats — @sanity/cli

Compared against main (24081c33)

@sanity/cli

Metric	Value	vs main (24081c3)
Internal (raw)	2.2 KB	-
Internal (gzip)	838 B	-
Bundled (raw)	11.16 MB	-
Bundled (gzip)	2.10 MB	-
Import time	881ms	+11ms, +1.2%

bin:sanity

Metric	Value	vs main (24081c3)
Internal (raw)	782 B	-
Internal (gzip)	423 B	-
Bundled (raw)	9.87 MB	-
Bundled (gzip)	1.78 MB	-
Import time	2.27s	+0ms, +0.0%

🗺️ View treemap · Artifacts

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

📦 Bundle Stats — @sanity/cli-core

Compared against main (24081c33)

Metric	Value	vs main (24081c3)
Internal (raw)	108.1 KB	-
Internal (gzip)	27.0 KB	-
Bundled (raw)	21.72 MB	-
Bundled (gzip)	3.46 MB	-
Import time	780ms	+5ms, +0.6%

🗺️ View treemap · Artifacts

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

📦 Bundle Stats — create-sanity

Compared against main (24081c33)

Metric	Value	vs main (24081c3)
Internal (raw)	908 B	-
Internal (gzip)	483 B	-
Bundled (raw)	931 B	-
Bundled (gzip)	491 B	-
Import time	❌ ChildProcess denied: node	-

Details

• Import time regressions over 10% are flagged with ⚠️
• Sizes shown as raw / gzip 🗜️. Internal bytes = own code only. Total bytes = with all dependencies. Import time = Node.js cold-start median.

[github-actions]

Coverage Delta

File	Statements
packages/@sanity/cli/src/actions/deploy/deployApp.ts	10.5% (+ 5.0%)
packages/@sanity/cli/src/actions/deploy/deployChecks.ts	78.2% (±0%)
packages/@sanity/cli/src/actions/deploy/findUserApplication.ts	41.9% (+ 3.0%)

Comparing 3 changed files against main @ 24081c33f03cd7bde46e095bdaf06500f257f116

Overall Coverage

Metric	Coverage
Statements	74.3% (+ 0.0%)
Branches	64.2% (±0%)
Functions	69.2% (±0%)
Lines	74.8% (+ 0.0%)

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 76ec443. Configure here.}