mirror of
https://github.com/Yuyi-Oak/BlueArchiveToolkit.git
synced 2026-07-22 01:15:14 +08:00
ci(rust): 添加 Gitea host runner 工作流
补充自托管 Gitea host-runner workflow，并将项目状态、缺口、开发指南与路线图同步到当前实际情况。
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
BlueArchive Toolkit 采用 **Monorepo + 多语言混合** 架构，旨在构建一个可持续维护十年以上的工业级开源项目。
|
||||
|
||||
当前文档描述目标架构和已经落地的关键边界。它不是部署手册；当前可部署能力只有 Rust 官方资源同步任务。API Server、Web、Provider 编排和完整 Go CLI 仍未实现，实际实现状态以根目录 `CURRENT_STATUS.md` 和 `PROJECT_PLAN.md` 为准。
|
||||
当前文档描述目标架构和已经落地的关键边界。它不是部署手册；当前可部署能力只有 Rust 官方资源同步任务。API Server、Web、Provider 编排和 Go 产品入口仍未完成，实际实现状态以根目录 `CURRENT_STATUS.md` 和 `PROJECT_PLAN.md` 为准。
|
||||
|
||||
当前已经可用的官方资源入口包括：
|
||||
|
||||
|
||||
@@ -65,7 +65,7 @@ CAS V1 不以“能通过简单 put/get 测试”为完成标准。必须满足
|
||||
4. 并发写入相同内容测试通过。
|
||||
5. 损坏对象读取返回明确错误。
|
||||
6. 权限或路径错误有清晰错误类型。
|
||||
7. `cargo test --workspace` 和 `cargo clippy --workspace -- -D warnings` 通过。
|
||||
7. `cargo test --workspace` 和 `cargo clippy --workspace --all-targets -- -D warnings` 通过。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -148,14 +148,14 @@
|
||||
|
||||
### 3.5 导入到 CAS 和资源仓储
|
||||
|
||||
资源下载后，导入层会：
|
||||
当前实现已经提供资源导入能力，但官方同步下载完成后尚未自动作为用户级流程触发导入。手动或上层流程调用导入层时，它会：
|
||||
|
||||
1. 把 bundle 原始字节写入 CAS。
|
||||
2. 解析 UnityFS 基础摘要。
|
||||
3. 把资源条目写入 `ResourceRepository`。
|
||||
4. 记录资源路径、hash、大小和解析摘要。
|
||||
|
||||
这层的意义是把“下载到磁盘的文件”变成“可查询、可复用、可去重”的资源对象。
|
||||
这层的意义是把“下载到磁盘的文件”变成“可查询、可复用、可去重”的资源对象。把官方同步结果自动接入 CAS + `ResourceRepository` 仍属于 G-011 剩余工作。
|
||||
|
||||
对应实现主要在：
|
||||
|
||||
@@ -189,7 +189,7 @@
|
||||
|
||||
集成边界：
|
||||
|
||||
1. 当前生产和 Go CLI 默认集成路径是运行 `bat --json` 并消费结构化 report。
|
||||
1. 当前生产集成路径是运行 `bat --json` 并消费结构化 report；未来 Go CLI 若继续作为产品入口，也应优先使用该进程边界或 daemon RPC。
|
||||
2. systemd、容器或上层 Go 进程只负责守护 `bat --watch` / `bat --daemon`，不直接接管下载器内部状态。
|
||||
3. `bat-ffi` 只允许作为可选无状态 C ABI 兼容层，用于 Manifest inspect 和 sync plan 这类一次性 JSON helper；它不是官方同步 daemon、下载器、资源锁、CAS handle 或主控制面的承载位置。
|
||||
|
||||
@@ -304,7 +304,7 @@ JSON-RPC 2.0 服务，是面向上层服务（Go 层）的**主要跨语言边
|
||||
|
||||
- Go 层负责：BlueArchive 客户端请求处理、HTTP API、鉴权、内容分发，
|
||||
以及作为 RPC client 调用本机 daemon（连接 `bat.sock`，每行一个
|
||||
JSON-RPC 请求/响应）。
|
||||
JSON-RPC 请求/响应）。当前 Go 产品入口尚未完成，`cmd/bat` 仍是试验骨架。
|
||||
- Rust daemon 负责：官方资源自动拉取与校验、catalog 更新检查、
|
||||
版本状态与发布、任务队列/日志/错误/进度管理等长期状态型工作。
|
||||
- Go 层**不**直接嵌入 Rust FFI，不直接读写 daemon 的状态文件与资源
|
||||
|
||||
+10
-8
@@ -1,6 +1,6 @@
|
||||
# 稳定工程基线指南
|
||||
|
||||
- **更新时间**：2026-07-06
|
||||
- **更新时间**：2026-07-20
|
||||
- **目标**：让工作区处于可继续开发核心功能的可信状态。
|
||||
|
||||
---
|
||||
@@ -13,7 +13,7 @@
|
||||
2. 根目录只保留入口文档和工程配置。
|
||||
3. 旧报告归档，且不再和当前状态混淆。
|
||||
4. Rust workspace 成员显式列出。
|
||||
5. Go 尚未实现时，Makefile 不误报失败。
|
||||
5. Go 产品入口尚未完成时，Makefile 不把骨架包误报为完整产品。
|
||||
6. 当前缺口有集中清单和关闭顺序。
|
||||
7. 架构边界有 ADR 记录。
|
||||
8. 基础验证命令通过。
|
||||
@@ -36,14 +36,16 @@ make lint
|
||||
```bash
|
||||
cargo test --workspace
|
||||
cargo check --workspace
|
||||
cargo clippy --workspace -- -D warnings
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
go test ./...
|
||||
go vet ./...
|
||||
```
|
||||
|
||||
说明：
|
||||
|
||||
1. 当前没有 Go 产品入口，因此 Go build/test/check/fmt/lint 会在空 Go 阶段明确跳过。
|
||||
2. 如果后续新增 Go package，必须让 `go test ./...` 和 `go vet ./...` 纳入硬性验证。
|
||||
3. 当前 `golangci-lint` 可选；当 Go 代码进入主要开发阶段后，应纳入 CI。
|
||||
1. 当前已有 `cmd/bat` 和 `internal/ffi` 骨架，但没有 Go 产品级测试覆盖；`go test ./...` 出现 `[no test files]` 不代表 CLI/API 已完成。
|
||||
2. 如果后续新增 Go 产品 package，必须让 `go test ./...` 和 `go vet ./...` 纳入硬性验证。
|
||||
3. 当前 `golangci-lint` 可选；当 Go 代码进入主要开发阶段后，应纳入本地门禁。
|
||||
4. 官方同步相关修改必须额外运行 `cargo test -p bat-infrastructure --bin bat -- --nocapture`。
|
||||
|
||||
---
|
||||
@@ -88,10 +90,10 @@ git check-ignore -v Cargo.lock CLAUDE.md AGENTS.md CONTRIBUTING.md
|
||||
|
||||
CAS V1 和 Rust 官方同步闭环完成后，下一阶段优先推进：
|
||||
|
||||
1. Go CLI 的 `doctor` 和基础命令框架。
|
||||
1. 收敛 Go 产品入口：当前 `cmd/bat` 仅是试验骨架，不能视为完成。
|
||||
2. 按 `docs/guides/official-full-pull-smoke.md` 执行真实官方网络全量下载 smoke，并保留隔离目录报告。
|
||||
3. 官方同步结果接入 CAS + ResourceRepository。
|
||||
4. AssetBundle UnityFS 解析。
|
||||
4. AssetBundle UnityFS 引擎级解析。
|
||||
|
||||
优先阅读：
|
||||
|
||||
|
||||
@@ -127,9 +127,11 @@ git push origin feature/your-feature-name
|
||||
cargo fmt --check
|
||||
cargo test --workspace
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
go test ./...
|
||||
go vet ./...
|
||||
```
|
||||
|
||||
Go CLI 尚未实现时，`go test ./...` 可能没有产品级 package 可运行；Makefile 会在空 Go 阶段清晰跳过。
|
||||
Go 产品入口尚未完成，但仓库已有 `cmd/bat` 与 `internal/ffi` 骨架。提交前应运行 `go test ./...` 和 `go vet ./...`；目前输出可能只有 `[no test files]`，这代表缺少 Go 产品测试覆盖，不代表 Go CLI 已完成。
|
||||
|
||||
### 常用聚焦命令
|
||||
|
||||
@@ -144,7 +146,7 @@ cargo clippy -p bat-core -p bat-adapters -p bat-infrastructure --all-targets --
|
||||
|
||||
官方资源同步、下载、daemon、status、verify 或 repair 相关改动必须至少覆盖 `bat-infrastructure` 和 `bat` 二进制测试。
|
||||
|
||||
`bat-ffi` 只是可选无状态 C ABI 兼容层。修改 FFI 导出、JSON schema、错误返回或 `internal/ffi` CGO 包装时必须运行 `cargo test -p bat-ffi -- --nocapture`；Go CLI 和生产同步默认应通过 `bat --json` 进程边界集成。
|
||||
`bat-ffi` 只是可选无状态 C ABI 兼容层。修改 FFI 导出、JSON schema、错误返回或 `internal/ffi` CGO 包装时必须运行 `cargo test -p bat-ffi -- --nocapture`；未来 Go 产品入口和生产同步默认应通过 Rust `bat --json` 或 daemon RPC 进程边界集成。
|
||||
|
||||
### 集成测试
|
||||
|
||||
@@ -215,7 +217,7 @@ cargo fetch
|
||||
|
||||
### 3. FFI 兼容层问题
|
||||
|
||||
`bat-ffi` 不是主集成边界，只用于需要 C ABI 的兼容场景。默认 Go CLI 集成优先运行 Rust `bat --json`。
|
||||
`bat-ffi` 不是主集成边界，只用于需要 C ABI 的兼容场景。未来 Go 产品入口集成优先运行 Rust `bat --json` 或调用 daemon RPC。
|
||||
|
||||
重新构建兼容库：
|
||||
```bash
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 当前实现缺口清单
|
||||
|
||||
- **更新时间**：2026-07-18
|
||||
- **更新时间**：2026-07-20
|
||||
- **用途**：集中跟踪当前代码中的占位实现、设计缺口和下一步验收项。
|
||||
- **权威计划**：`../../PROJECT_PLAN.md`
|
||||
|
||||
@@ -107,30 +107,32 @@
|
||||
- 并发写入相同内容只产生一个对象。
|
||||
- 读取时 Hash 不匹配会返回明确错误。
|
||||
|
||||
### G-005：AssetBundle 解析器仍是占位
|
||||
### G-005：AssetBundle 引擎解析器仍未完成
|
||||
|
||||
现象：
|
||||
|
||||
- `crates/bat-assetbundle/src/parser.rs` 只有 `Parser::name`。
|
||||
- `types.rs` 只有 `AssetType::TextAsset`。
|
||||
- `adapters/src/unity/unity_2021_3.rs` 已能解析 UnityFS header、block info、directory，并校验 directory `offset+size` 不越界；这属于 adapter 层基础摘要能力，不等于 `bat-assetbundle` 引擎已完成。
|
||||
- 仍没有对象表、TypeTree、TextAsset、MonoBehaviour、ScriptableObject 或可扩展提取入口。
|
||||
|
||||
影响：
|
||||
|
||||
- 无法解析真实 UnityFS。
|
||||
- 可以对部分 UnityFS 样本做基础结构校验，但无法完成真实资源对象解析和文本提取。
|
||||
- 无法提取 TextAsset 或配置文本。
|
||||
|
||||
验收：
|
||||
|
||||
- 能解析结构化测试样本。
|
||||
- 支持 UnityFS header、blocks、directory、metadata。
|
||||
- `crates/bat-assetbundle` 能解析结构化测试样本和隔离真实样本。
|
||||
- 支持 UnityFS header、blocks、directory、metadata、object table。
|
||||
- 错误包含偏移和字段上下文。
|
||||
|
||||
### G-006：Patch 引擎仍是占位
|
||||
|
||||
现象：
|
||||
|
||||
- `binary::apply_patch` 返回空 `Vec`。
|
||||
- `json::apply_json_patch` 返回空字符串。
|
||||
- `binary::apply_patch` 明确返回 `PatchError::ApplyFailed`，提示 Binary patch 尚未实现。
|
||||
- `json::apply_json_patch` 明确返回 `PatchError::ApplyFailed`，提示 JSON patch 尚未实现。
|
||||
|
||||
影响：
|
||||
|
||||
@@ -150,7 +152,8 @@
|
||||
现象：
|
||||
|
||||
- `AddressablesCatalogDriver` 已能解析当前真实形态 JSON catalog fixture/golden。
|
||||
- 已输出 path、hash、size、resource_type、address、dependencies、metadata。
|
||||
- 已输出 path、hash、size、resource_type、address、dependencies、metadata，并已提取 `m_Crc` 到 `crc` 字段。
|
||||
- `bat-core` 已提供 `crc32_ieee` 和 `ResourceEntry::verify_downloaded_bytes`，SQLite `ResourceRepository` 已有 `crc` 列迁移。
|
||||
- 仍需覆盖更多官方 catalog 结构变体、二进制/压缩字段组合和更明确的失败诊断。
|
||||
|
||||
影响：
|
||||
@@ -160,22 +163,30 @@
|
||||
验收：
|
||||
|
||||
- 能解析项目目标版本的真实 Catalog 样本集合。
|
||||
- 解析结果包含资源 key、provider、dependency、hash、size、path。
|
||||
- 解析结果包含资源 key、provider、dependency、hash、size、path、CRC。
|
||||
- 对不支持的 catalog 结构返回明确错误，而不是静默丢字段。
|
||||
|
||||
---
|
||||
|
||||
## 3. 应用层缺口
|
||||
|
||||
### G-008：Go CLI 尚未实现
|
||||
### G-008：Go CLI 产品入口尚未完成
|
||||
|
||||
状态：**已关闭（并入 G-009）**
|
||||
状态：**未完成（此前“并入 G-009”只是短期跟踪调整，不代表能力完成）**
|
||||
|
||||
处理结果：
|
||||
现象：
|
||||
|
||||
- 用户命令入口继续由功能完整的 Rust `bat` binary 承担（one-shot / watch / daemon / status / verify / repair / doctor / clean-stable 等已可用），Go 侧不再做重复的产品级用户 CLI。
|
||||
- Go 侧职责收敛为架构文档 §7.2 划定的方向：BlueArchive 客户端请求处理、HTTP API、内容分发。这部分并入 G-009（`bat-api`）。
|
||||
- 现有 `cmd/bat` cgo 试验骨架不再作为产品入口目标，另行清理。
|
||||
- 当前可用的用户同步/运维入口是 Rust `bat` binary。
|
||||
- `cmd/bat` 已存在，但仅有 `doctor`、`manifest inspect`、`sync plan` 试验能力；`doctor` 只输出固定 `ok`，`manifest`/`sync` 依赖可选 CGO/FFI helper。
|
||||
- Go 侧尚未实现通过 Rust `bat --json` 或 daemon RPC 包装官方同步命令、稳定 human/json 输出、真实 doctor 检查和端到端测试。
|
||||
- 如果项目决策改为“用户 CLI 永久由 Rust `bat` 承担，Go 只做 `bat-api`/服务层”，必须同步更新 `AGENTS.md`、`PROJECT_PLAN.md` 和 issue 跟踪；在完成该决策前，不能把 Go CLI 写成已完成。
|
||||
|
||||
验收：
|
||||
|
||||
- `cmd/bat doctor` 做真实环境诊断，而不是固定字符串。
|
||||
- `cmd/bat sync` 能通过 Rust `bat --json` 或 RPC 触发/查询官方同步，不走 FFI 控制下载器或 daemon。
|
||||
- human/json 输出、退出码和错误码与 Rust `bat` 契约一致。
|
||||
- `go test ./...`、`go vet ./...` 覆盖命令解析、错误输出和至少一个 mocked Rust 边界。
|
||||
|
||||
### G-009：API Server（`bat-api`，仿官方 API）尚未实现
|
||||
|
||||
@@ -201,7 +212,7 @@
|
||||
- 真机 e2e：daemon 发布 fixture release → 启动 `bat-api` → 按官方 URL 与鉴权头请求 server-info / catalog / bundle / launcher 链，断言字节与形态正确、验签生效（缺签/错签被拒）。
|
||||
- 统一错误结构与官方响应 envelope 对齐；Makefile 增加 Go 构建/测试目标。
|
||||
|
||||
排期：P2，排在 issue #2 / #3 / #17（完善 Rust `bat` 后端）之后启动。
|
||||
排期：P2，排在 issue #17 验收收口以及 issue #2 / #3 的解析能力继续推进之后启动；可与 G-008 的 Go 产品入口边界收敛并行。
|
||||
|
||||
### G-010：Web 管理后台尚未实现
|
||||
|
||||
@@ -391,7 +402,8 @@
|
||||
处理结果：
|
||||
|
||||
- 明确决策：本项目不加入 GitHub Workflows，也不引入其他托管 CI。
|
||||
- 质量门禁由本地默认验证命令承担：提交前执行 `cargo fmt` / `cargo clippy --workspace --all-targets -- -D warnings` / `cargo test --workspace`（见 `docs/guides/development.md` 与 `docs/guides/baseline.md`）。
|
||||
- 目前补充了自托管 Gitea host-runner workflow（`.gitea/bat.yml` 与 `.gitea/workflows/bat.yml`），仅用于 Rust workspace 的构建和测试，不改变“不引入托管 CI”的决策。
|
||||
- 质量门禁由本地默认验证命令和自托管 workflow 共同承担：提交前执行 `cargo fmt` / `cargo clippy --workspace --all-targets -- -D warnings` / `cargo test --workspace`（见 `docs/guides/development.md` 与 `docs/guides/baseline.md`）。
|
||||
- 发布类检查（build、smoke）由 `Makefile` 与 `scripts/` 下的可重复脚本承担（如 `make official-smoke`）。
|
||||
|
||||
限制：
|
||||
@@ -457,10 +469,11 @@
|
||||
|
||||
## 6. 当前关闭顺序建议
|
||||
|
||||
1. issue #2 / #3 / #17（完善 Rust `bat` 后端：Addressables 可校验字段、UnityFS 基础解析、下载多线程）
|
||||
2. G-007 / G-005（对应上面 #2 / #3 的缺口条目）
|
||||
3. G-009（`bat-api`，仿官方 API 的 Go HTTP 服务，issue #19）
|
||||
4. G-011（官方同步结果接入 CAS + ResourceRepository 用户级工作流）
|
||||
5. G-012 / G-006（翻译系统、Patch 引擎）
|
||||
1. issue #17 验收并关闭或更新范围：多线程下载与指数退避实现已合入，但 GitHub issue 仍 open。
|
||||
2. issue #2 / G-007：继续扩大 Addressables 可校验字段和结构变体覆盖。
|
||||
3. issue #3 / G-005：把 UnityFS 基础摘要推进到 `bat-assetbundle` 引擎级解析。
|
||||
4. G-011：官方同步结果接入 CAS + ResourceRepository 用户级工作流。
|
||||
5. G-008 / G-009：收敛 Go 产品入口边界，并实现 `bat-api`（issue #19）。
|
||||
6. G-012 / G-006：翻译系统、Patch 引擎。
|
||||
|
||||
这个顺序优先把 Rust `bat` 后端做扎实（解析能力 + 下载性能），再对外提供仿官方 API 服务端，最后推进资源索引编排、翻译和补丁。G-008 已并入 G-009（用户 CLI 由 Rust `bat` 承担）；G-018 已固化为可重复 smoke 命令并关闭；G-017 已按"不引入托管 CI"决策关闭。
|
||||
这个顺序优先把 Rust `bat` 后端做扎实（解析能力 + 下载性能），再把官方同步结果进入可查询资源库，之后收敛 Go 入口和仿官方 API 服务端，最后推进翻译和补丁。G-018 已固化为可重复 smoke 命令并关闭；G-017 已按“不引入托管 CI”决策关闭。
|
||||
|
||||
Reference in New Issue
Block a user