feat(hosting): hosting CLI owns the deploy flags; --hostname names the GCP service - #6937
feat(hosting): hosting CLI owns the deploy flags; --hostname names the GCP service#6937Kastier1 wants to merge 4 commits into
Conversation
…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 SummaryThe 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.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| 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
Merging this PR will not alter performance
Comparing Footnotes
|
…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>
There was a problem hiding this comment.
💡 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".
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>
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>
reflex deploy becomes a shim over the hosting CLI
reflex deploypreviously 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:reflex_cli.v2.deploy_options.deploy_options()exports the hosting-owned click options, each named after thedeploy()keyword argument it feeds (--description→deployment_description,--region→regions, ...).reflex deploydeclares 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).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*.devpin does not help either, since the workspace builds as0.1.70.postN.devM). Since the current floor admits a hosting CLI withoutdeploy_options— andpip install -U reflexcan leave an already-satisfied one untouched — that is a supported install, so neither crashing on import nor refusing to deploy is acceptable there.reflex deploytherefore falls back to_baseline_deploy_options(), a copy of the flags as of this release, andtest_the_baseline_matches_the_hosting_clis_own_listkeeps 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 deploymust injectexport_fnand 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.deployparameter (a name landing only in**kwargswould parse and silently do nothing), and aCliRunnertest driving the realreflex deployasserting 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),
--hostnamedoubles as the requested Cloud Run service name, sent asservice_nameon the provider pin — so the service in the customer's GCP console reads like the app's URL instead ofapp-<uuid>. Server support forservice_nameships separately in the control plane; older servers ignore the field and mint/derive as today.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