# B9 自动部署

Gitea workflow 位于 `.gitea/workflows/deploy-b9.yml`。

## 触发方式

- 推送 `b9` 分支：构建正式版，同步到 `s3://luxsin-app-bucket/b9/v2/`，刷新 CloudFront `EUS4XQ8Y0W2ZV` 的 `/b9/v2/*`。
- Actions 手动运行：可选择 `prod` 或 `test`；测试环境同步到 `s3://luxsin-app-bucket/b9/test/`，刷新 `/b9/test/*`。
- 使用现有 `windows-cross` Runner（Linux x64 Docker 镜像），安装 Node.js 24、pnpm 11.5.2 和 AWS CLI。
- 同一时间只运行一个 B9 部署，避免多个同步任务互相覆盖。

## 一次性配置

在实际托管 `b9` 分支的 Gitea 仓库中，进入「设置 → Actions」：

### Secrets

| 名称 | 用途 |
| --- | --- |
| `AWS_ACCESS_KEY_ID` | 部署账号的访问密钥 ID |
| `AWS_SECRET_ACCESS_KEY` | 对应的访问密钥 |
| `AWS_SESSION_TOKEN` | 仅临时凭据需要；过期后需要更新整组凭据 |

不要提交本机 `.aws` 或把密钥写入 workflow。部署身份应仅有目标桶 `b9/v2/`、`b9/test/` 前缀所需的同步读写删除权限，以及指定 CloudFront 分配的创建失效权限；若存储桶使用自定义 KMS 加密，还需相应 KMS 权限。

### Variables

| 名称 | 用途 |
| --- | --- |
| `AWS_REGION` | 填写现有 S3 存储桶所在区域，必填 |
| `VITE_AI_API_URL` | 生产可访问的 AI 服务地址，可选；未填时使用应用内置默认地址 |

Runner 必须能领取此仓库的任务，并能够访问 GitHub Actions、npm、AWS CLI 下载站、S3 和 CloudFront API。当前本地 origin 为 `https://repo.luxsin.com.cn/audio/controller-v2.git`，需要在这台 Gitea 对应仓库配置 Runner 和上述参数；旧 Gitea 的仓库级 Runner 不会自动跨实例生效。

## 部署规则

复用 `scripts/deploy.sh`，CI 执行 `DEPLOY_PROJECT_NAME=b9 bash scripts/deploy.sh prod -yr`。`-y` 跳过人工确认，`-r` 刷新缓存；本地未加 `-y` 时仍需确认。

默认上传 images，与现有脚本默认行为一致。`aws s3 sync --delete` 会删除目标前缀中本次构建不存在的对象，部署前会校验入口文件避免上传空目录。需要排除 images 的手工部署仍可使用 `-i`。

每次部署会产生 S3 请求和 CloudFront 缓存失效请求，按账号实际用量计费。workflow 不上传或读取本机未跟踪的 `.env`，构建所需公开配置应放入 Actions Variables。

## 分支与型号目录

`main` 对应 `x8`，其余已知型号分支 `x9`、`b9`、`bd9`、`bh9` 使用分支名作为目录。CI 会设置 `DEPLOY_PROJECT_NAME`，构建路径与部署目标保持一致；本地脚本也支持相同映射。

目前自动触发范围仍仅为 `b9`，未扩大其他分支的自动生产部署。其他分支需包含对应 workflow，启用前需确认部署范围；不要覆盖各分支的型号专用代码。AWS 权限也应按实际启用的型号前缀配置。