Build config for mainland China deployment in release workflow

[nighca]

This pull request adds support for a mainland China-specific production build and deployment of the account frontend. It introduces a new build step in the GitHub Actions workflow and provides a dedicated environment configuration for the China deployment.

Mainland China deployment support:

• Added a new build step in the .github/workflows/release.yml workflow to generate a production build of the account frontend specifically for mainland China using the production.cn environment.
• Introduced a new environment file spx-gui/.env.production.cn containing China-specific configuration variables such as API endpoints, user content URLs, Sentry DSN, and default language settings.

[gemini-code-assist]

Code Review

This pull request adds a new production environment configuration file, spx-gui/.env.production.cn. The review feedback recommends explicitly disabling the AIGC service by adding VITE_DISABLE_AIGC='true' to this file, as the service is not yet ready for production.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[nighca]

先补上这份配置（会影响 app account 的 Sentry DSN 和默认 UI 语言），后续还有两件事情要做：

1. Vercel 部署 app xbuilder 时也使用入库的这份配置而不是在 Vercel 平台上的环境变量配置
2. 拆分 app xbuilder & app account 所使用的 env

[nighca]

Follow-up issue created: #3299

[fennoai]

Summary

This PR adds a mainland China-specific build and deploy step to the release workflow, together with a new .env.production.cn environment file. The intent is clear and the approach is consistent with the existing patterns. A few issues are worth addressing before merge.

---

Findings

1. NODE_ENV=production.cn overrides a built-in NODE_ENV=production in the npm script — fragile mechanism

The build:account script in package.json is:

NODE_ENV=production vite build --config vite.config.account.ts --mode ${NODE_ENV:-production}

The workflow step passes NODE_ENV=production.cn to this script, which works because the shell expands ${NODE_ENV:-production} to production.cn (from the inherited env) before the inline NODE_ENV=production prefix takes effect for the Vite child process. Vite then uses --mode production.cn and loads .env.production.cn as intended.

However, production.cn is a non-standard NODE_ENV value. NODE_ENV conventionally takes production / development / test. Many libraries — including Vite plugins, Vue, and bundler treeshaking logic — branch on the literal string "production". The Vite child process receives NODE_ENV=production (from the script's inline assignment), so this is likely fine in practice, but the mechanism is subtle and undocumented.

A simpler and more explicit approach would be a dedicated build:account:cn script in package.json that passes --mode production.cn directly, keeping NODE_ENV=production as the canonical value throughout:

"build:account:cn": "NODE_ENV=production vite build --config vite.config.account.ts --mode production.cn"

Then the workflow step becomes a straightforward npm run build:account:cn, without any NODE_ENV override.

---

2. Two sequential full Vite builds share the same dist output directory — fragile ordering and doubled build time

Both builds write to spx-gui/dist. The correct deployment relies on this exact step ordering:

1. Build (production) → dist
2. Deploy builder_account from dist
3. Build (production.cn) → overwrites dist
4. Deploy builder_account_cn from dist

This is currently correct, but any future reordering or parallelization would silently deploy the wrong config to one of the two environments. There is also no clean step between builds, so stale hashed assets from the first build can linger.

Recommend building each variant into a distinct output directory (e.g. dist and dist-cn via Vite --outDir) and pointing each deploy step at its own directory. This removes the hidden ordering coupling and makes the workflow self-documenting.

As a secondary benefit, the two builds could then run as parallel jobs (matrix strategy over mode: [production, production.cn]), cutting the release job's wall-clock time roughly in half rather than running two full sequential Vite builds.

---

3. Sentry DSN routes CN error reports to a US ingest endpoint

VITE_SENTRY_DSN uses o4509472134987776.ingest.us.sentry.io. For a deployment specifically targeting mainland China, routing Sentry traffic to a US endpoint may result in unreliable or blocked error reporting due to network connectivity constraints. Worth confirming this actually reaches Sentry from within the CN network, or switching to a Sentry EU/regional endpoint.

---

4. VITE_ACCOUNT_OAUTH_CLIENT_ID="1" — confirm this is not a placeholder

A client ID of "1" is unusual for a production OAuth configuration. Please confirm this is the real registered client ID for the CN deployment and not a copied placeholder value.

---

5. Missing header comment (minor)

See inline comment.

---

View job run