Skip to content

feat(hosting): hosting CLI owns the deploy flags; --hostname names the GCP service - #6937

Open
Kastier1 wants to merge 4 commits into
mainfrom
simon/deploy-shim-and-gcp-service-name
Open

feat(hosting): hosting CLI owns the deploy flags; --hostname names the GCP service#6937
Kastier1 wants to merge 4 commits into
mainfrom
simon/deploy-shim-and-gcp-service-name

Conversation

@Kastier1

@Kastier1 Kastier1 commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

reflex deploy becomes a shim over the hosting CLI

reflex deploy previously re-declared every hosting flag itself, so each new hosting-cli deploy option (instance bounds, GCP connection, strategy, ...) also required a framework release. Now the hosting CLI owns its flag list:

  • New reflex_cli.v2.deploy_options.deploy_options() exports the hosting-owned click options, each named after the deploy() keyword argument it feeds (--descriptiondeployment_description, --regionregions, ...).
  • reflex deploy declares only the framework-owned flags (--exclude-from-backend, --ssr), adopts the rest from the installed hosting CLI at import time, and forwards parsed values through **kwargs (multi-value options normalized to lists, matching the pre-shim behavior).
  • The dependency floor is deliberately left alone, and the old flag list survives as a temporary baseline. A floor naming an unpublished hosting-cli cannot resolve in check_min_deps (the root package's isolated build env resolves reflex's own requirements from the index, where the workspace editable is not visible; a *.dev pin does not help either, since the workspace builds as 0.1.70.postN.devM). Since the current floor admits a hosting CLI without deploy_options — and pip install -U reflex can leave an already-satisfied one untouched — that is a supported install, so neither crashing on import nor refusing to deploy is acceptable there. reflex deploy therefore falls back to _baseline_deploy_options(), a copy of the flags as of this release, and test_the_baseline_matches_the_hosting_clis_own_list keeps the two the same set so a deploy accepts the same flags either way. Delete the baseline together with the floor bump to >= 0.1.71, once that hosting-cli release publishes.

A pure click alias doesn't work here because reflex deploy must inject export_fn and its compile/export flags — the shim keeps those framework-side and moves everything else.

Two drift guards: a test asserting every exported option name is an explicit cli.deploy parameter (a name landing only in **kwargs would parse and silently do nothing), and a CliRunner test driving the real reflex deploy asserting flags arrive under the lib's names.

--hostname names the Cloud Run service on GCP

On the deploy that first lands an app on GCP (fresh app or provider switch), --hostname doubles as the requested Cloud Run service name, sent as service_name on the provider pin — so the service in the customer's GCP console reads like the app's URL instead of app-<uuid>. Server support for service_name ships separately in the control plane; older servers ignore the field and mint/derive as today.

  • Only the first-landing pin carries a name: it is the moment the server would mint one, and the only time a request cannot collide with a name pinned to a live service. Redeploys of an app already on GCP never send it.
  • A hostname the service-name grammar refuses (leading digit, over 49 chars, the reserved app-<uuid> shape) is skipped with a note and the server mints from the app name — an invocation that deployed yesterday still deploys today.

Linear: ENG-11613

🤖 Generated with Claude Code

Review in cubic

…e GCP service

reflex deploy becomes a thin shim: it declares only the framework-owned
flags (--exclude-from-backend, --ssr) and adopts every hosting flag from
the new reflex_cli.v2.deploy_options, forwarding parsed values as keyword
arguments. A new hosting deploy flag now ships with a hosting-cli release
alone, no framework release required.

On the deploy that first lands an app on GCP, --hostname doubles as the
requested Cloud Run service name (sent as service_name on the provider
pin). A hostname the service-name grammar refuses is skipped with a note
so the server mints a name instead of the deploy failing; later GCP
deploys never send one, since the name is pinned to the live service.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@greptile-apps

greptile-apps Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR moves hosting-owned deploy options into the hosting CLI while retaining a compatibility baseline for older supported versions. It also derives the initial managed-GCP Cloud Run service name from a valid hostname.

  • Exports reusable Click deploy options and forwards them through the framework shim.
  • Preserves deployment compatibility when the installed hosting CLI predates the option-export module.
  • Sends a validated hostname as the service name when an app first lands on GCP.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
packages/reflex-hosting-cli/src/reflex_cli/v2/deploy_options.py Centralizes the hosting-owned Click deploy options and maps their parsed names to explicit hosting deploy parameters.
reflex/reflex.py Converts reflex deploy into a forwarding shim while retaining framework-owned export flags and an older-hosting-CLI fallback.
packages/reflex-hosting-cli/src/reflex_cli/v2/cli.py Validates and forwards a hostname-derived Cloud Run service name only during the initial transition to managed GCP.
packages/reflex-hosting-cli/src/reflex_cli/utils/hosting.py Extends the provider-selection request to carry an optional Cloud Run service name.
tests/units/test_reflex.py Covers option adoption, fallback compatibility, help rendering, and forwarding through the real top-level command.
tests/units/reflex_cli/v2/test_cli.py Covers service-name normalization, rejection, and provider-pin forwarding behavior.

Reviews (4): Last reviewed commit: "tighten the drift guard, and let its tes..." | Re-trigger Greptile

Comment thread packages/reflex-hosting-cli/src/reflex_cli/utils/hosting.py
@codspeed-hq

codspeed-hq Bot commented Aug 24, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 27 untouched benchmarks
⏩ 8 skipped benchmarks1


Comparing simon/deploy-shim-and-gcp-service-name (cc7d482) with main (126ef6d)

Open in CodSpeed

Footnotes

  1. 8 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

…g CLI

The new shim test invoked the real command body, which writes REFLEX_SSR
and REFLEX_COMPILE_CONTEXT straight into os.environ; that leaked into
every later test in the process and surfaced several files away as an app
harness failing to reset a leaked prod env mode. It now restores the
environment.

The hosting-cli floor bump is dropped: an unpublished floor cannot
resolve in check_min_deps (the root package's build env resolves its own
runtime requirements from the index, where the workspace editable is not
visible), and the floor on main already admits a hosting CLI without
deploy_options. So the import is tolerated instead — the rest of the CLI
loads as before and reflex deploy alone reports that reflex-hosting-cli
needs upgrading, rather than every reflex command dying on an import for
a flag list only deploy reads.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@Kastier1
Kastier1 marked this pull request as ready for review August 24, 2026 19:06
@Kastier1
Kastier1 requested a review from a team as a code owner August 24, 2026 19:06

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 02085bea6c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread reflex/reflex.py Outdated
Review was right that refusing the deploy regresses a supported install:
the floor is still >= 0.1.66, and pip's default upgrade strategy leaves an
already-satisfied reflex-hosting-cli untouched, so upgrading reflex alone
lands on a version without the module -- and reporting 'upgrade the
hosting CLI' there takes away a deploy that worked before.

The flags now fall back to _baseline_deploy_options(), a copy of the list
as of this release, so a deploy accepts the same flags whichever side owns
them. A test holds the two lists to the same set of names, and both the
baseline and the fallback go when the floor moves to the first release
that ships deploy_options.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

1 issue found and verified against the latest diff

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/reflex-hosting-cli/src/reflex_cli/v2/cli.py">

<violation number="1" location="packages/reflex-hosting-cli/src/reflex_cli/v2/cli.py:160">
P2: When `--hostname` is a full custom domain such as `myapp.reflex.dev`, this line validates the entire domain and skips `service_name`. Derive the service name from the same normalized subdomain that `get_hostname()` reserves.</violation>
</file>

Reply with feedback, questions, or to request a fix.

Re-trigger cubic

Comment thread tests/units/reflex_cli/v2/test_deploy_options.py Outdated
Comment thread tests/units/test_reflex.py Outdated
Comment thread packages/reflex-hosting-cli/src/reflex_cli/v2/cli.py

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

All reported issues were addressed across 11 files

Requires human review: Auto-approval blocked because this review re-detected 2 unresolved issues already reported by Cubic.

Re-trigger cubic

Two review points on the tests. The forwardability check accepted *args
and positional-only parameters, which cannot receive a forwarded keyword,
so an option named after one would have passed the guard and then been
dropped into **kwargs at the call -- the exact failure it exists to catch.

And tests/units/test_reflex.py imported deploy_options at module scope
while containing the test for a hosting CLI that lacks it, so collection
failed in the one environment the file is about. The two tests that need
the list import it themselves.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.

1 participant