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 权限也应按实际启用的型号前缀配置。

2.8 KiB Raw Blame History Unescape Escape