[netanelgilad]

Note

Description

base44 deploy --git-hash <hash> now ships a project's built site through the deployments API — the same lane base44 site deploy uses — addressed by that commit, and publishes it, so a full-stack build's Cloudflare worker ships instead of being silently dropped by the unified deploy. The lane also loses its BASE44_DEPLOYMENTS_API env gate: --git-hash / --concurrency are always registered on site deploy, and the flag itself — never the checkout's HEAD, never an env var — is what selects the lane. Without --git-hash both commands keep the legacy tar.gz archive upload, which goes live as before; a worker build, which that upload cannot carry, now fails asking for the flag before anything ships.

Deploying and publishing stay separate acts. base44 deploy --git-hash publishes what it shipped, because the archive upload it replaces always left the app live. base44 site deploy --git-hash does not — --publish asks for it — because its main caller is the platform's build step running against builder-managed apps, which are published from the builder; the command now says so, pointing at --publish, when it leaves production alone.

Related Issue

None

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Other (please describe):

Changes Made

• base44 deploy --git-hash <hash> ships the site through the deployments API — deployAll() routes the site step through a new deployProjectSite() / shipCommit() pair that calls deployToDeployments() and then publishes the result, so a full-stack build's worker is deployed instead of dropped. --concurrency deliberately stays off this command: the caller uploading at scale is site deploy.
• The flag, and only the flag, selects the lane. resolveGitHash() is gone — git rev-parse HEAD is never consulted for a deployment, so nothing is inferred from the local checkout. Versions keep reading HEAD as provenance (resolveProvenanceCommit(), which now does its own hex check).
• New publishDeployment() in core/site/api.ts — POST /deploy with { git_commit_hash }, then reads the app URL from published-url. The response body is deliberately not parsed: it differs between a logged-in user and an API key and carries nothing the CLI doesn't already know.
• Builder-managed apps degrade gracefully: a publish rejected with error.code git_commit_hash_not_supported is not a failed deploy — the resources and the build did ship, so the CLI reports that production was left where it was and succeeds. Any other publish error still fails the command.
• A worker build with no commit fails before anything ships (workerBuildNeedsGitHashError()): deployAll() checks for a .wrangler/deploy/config.json artifact up front, and site deploy checks before its first request. A static build without --git-hash keeps deploySite(), which publishes as it always did.
• site deploy reports when it did not publish — "Not published: production still serves its previous build. Run again with --publish to serve this one." — and its --json document gains published: boolean alongside deploymentId and gitHash; the archive fallback now emits { appUrl, published: true }.
• hasResourcesToDeploy() is now async and counts a detected full-stack artifact as a site, so a worker-only project with no site.outputDirectory is no longer reported as "No resources found to deploy".
• Env gate removed: deploymentsApiEnabled() and BASE44_DEPLOYMENTS_API are gone from core/site/deployment.ts, and site deploy's deployTarball() branch becomes the no-commit deployArchive() fallback.
• Shared --git-hash parser: parseGitHash() extracted to cli/utils/git-hash.ts and reused by site deploy, deploy, and the versions commands' gitHashOption(), replacing duplicate copies of the same 7–64-hex-char check.
• New PublishedDeployment type (gitHash, appUrl) in core/site/schema.ts.
• Tests: new testkit mocks mockDeploymentPublish() / mockDeploymentPublishError() with a publishedCommits capture; mockSiteDeployError() renamed to mockDeploymentCreateError() and repointed at /deployments; a new "shipping the site" suite in deploy.spec.ts covering publish, builder-managed apps, publish failure and the no-commit archive fallback; site_deploy.spec.ts gains not-published / --publish / archive-fallback cases; fullstack_deploy.spec.ts asserts deploy -y refuses a worker build before any request; gate-off tests and givenEnv({ BASE44_DEPLOYMENTS_API }) dropped across the deploy specs.
• Docs: docs/deployments.md rewritten around deploy-vs-publish, the --git-hash opt-in, the remaining callers of the archive upload and the updated command UX; CHANGELOG.md entries added.

Testing

• I have tested these changes locally
• I have added/updated tests as needed
• All tests pass (npm test)

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• I have updated docs/ (AGENTS.md) if I made architectural changes

Additional Notes

• Behavior changes worth calling out: BASE44_DEPLOYMENTS_API becomes a no-op, so a caller that set it to reach the lane must now pass --git-hash instead; base44 deploy --git-hash publishes with no way to opt out (an earlier --no-publish was dropped before merge, since it read as covering every resource the deploy ships when only the site waits on a publish); and a full-stack build now fails asking for --git-hash on both commands instead of silently shipping a worker-less archive.
• Stale references left in the tree: docs/resources.md:116-121 still documents deploymentsApiEnabled() as an export of the site module, docs/versions.md:98,147 still describe resolveGitHash and BASE44_DEPLOYMENTS_API as live, core/version/gate.ts:8 repeats the latter, and tests/cli/static_site_deployments.spec.ts:296 still sets it (now a harmless no-op).
• The testing checkboxes are unchecked because the suite was not executed in this environment — dependencies are not installed here and the default npm test mode needs a build first. Coverage for the new paths lives in deploy.spec.ts, site_deploy.spec.ts, static_site_deployments.spec.ts, fullstack_deploy.spec.ts and build.spec.ts.

---

_{🤖 Generated by Claude | 2026-10-21 12:12 UTC | d4dd71d}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.1.33-pr.643.706636f

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.1.33-pr.643.706636f"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.1.33-pr.643.706636f"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.1.33-pr.643.706636f
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}

[netanelgilad]

Parking this as a draft.

• The base44 dev front door is split out to feat(dev): front the app's dev server with the SDK header contract #659. This PR now has only the deploy routing (deployments API as the default lane, env gate removed, deploy publishes).
• Full-stack deploys look set to go through Yury's base44-dev/apper#29340 (build/deploy pipeline) plus the CLI's base44 publish (versions API, behind BASE44_VERSIONS_API).
• Once #29340 lands, this PR will probably shrink to having base44 deploy use publish for worker builds.

---

Generated by Claude Code

[netanelgilad]

Back in review. The server side is settled: base44-dev/apper#26921 makes POST /deploy accept git_commit_hash for apps whose source Base44 doesn't manage, and it's in the merge queue. This PR now calls that instead of the dropped deployments/{git_hash}/publish route, and reads the app URL from published-url afterwards.

Merge order matters: release this only after #26921 is deployed. A server without it ignores the unknown git_commit_hash field and runs an ordinary latest-version publish instead of publishing the uploaded commit.

---

Generated by Claude Code

[netanelgilad]

test (ubuntu-latest, npm) failed on d52a878 in tests/cli/dev-security.spec.ts (the beforeEach that starts base44 dev): Port 40477 is already in use. This PR's last push only removes --no-publish from base44 deploy and doesn't touch the dev server or that spec. The same suite passed on all four matrix legs on the previous head, 6d264e8. The error comes from a port the dev server picks being taken by another process before it binds (dev-server/main.ts), not from anything this PR changes. No fix exists yet. I'll re-run the job once when the rest of the workflow finishes.

---

Generated by Claude Code