|
|
b6a6168e65
|
chore(module)!: module 路径随托管地迁移 gitcode → github
SDK 仓已迁到 GitHub 作为权威源，go module 路径同步：
`gitcode.com/JianFeeeee/homeagent-sdk` → `github.com/JianFeeeee/homeagentsdk`
## 范围
74 个文件：71 个 Go 源码 + go.mod/go.sum + hmapdev 模板 + CI 与打包脚本。
主仓（HomeAgent）侧对应改动是 6d38a164。本仓这些文件当时**不在工作树上**
（见下），所以那次的批量替换扫不到它们——这里是补偿。
## 为何这批文件当时不在工作树上（事故与恢复）
10-08 07:58 主仓做 checkout/cherry-pick 序列时，把本仓工作树的 20 个文件
误清理了（`example/*/plugin.go` + `plg.json`，10 个示例）。
根因是**结构误判**：本仓是「一目录两仓库」结构下主仓 `third_party/` 里的
**独立 git 仓库**，而主仓 .gitignore 忽略了 `example/`，于是它在主仓
`git status` 里不可见 —— 看着像「不受跟踪的构建产物」，实际是本仓受跟踪的源码。
已全部恢复（`git checkout -- <D 文件>`，只恢复删除、不动迁移改动），
20 个文件与 HEAD 逐字节一致。
**破坏的连锁后果**：恢复出来的 `plugin.go` 仍写着旧 module 路径，
因为迁移时它们已不在工作树上。所以这次补偿是必须的，不是可选优化。
## 保留 gitcode 引用
以下位置的 `gitcode` **有意保留**，不要"顺手清掉"：
- README.md / docs 里「二进制实际分发地址目前是 gitcode」的说明
- mkdocs.yml 的 gitcode 镜像链接（国内直连更快）
- `tools/hmapdev/templates.go` 里「SDK 已从 gitcode 迁到 GitHub」的注释
gitcode 仍是**只读镜像**（源码同步；release 附件暂时仍在那边）。
## 验证
- 本仓根 module：`go build ./...` + `go test ./...` 全通过
- 全部 20 个 example：`go vet` 通过（补偿前 10 个因旧 module 路径失败）
- example/qq：`go test` 通过，且能从源码 build 出可用 plugin 产物
|
2026-10-09 07:25:25 +08:00 |
|
|
|
c16411a77d
|
ci: 修 CI 自身的三处错误（本地能过 ≠ CI 能过）
首次跑出来的 8 个失败全是本 workflow 自己的问题，不是代码缺陷。
三条都属同一类：**命令本地验证过，但环境前提不同**。
## 1. hmapdev 交叉编译：在错误的目录跑（5 个平台全红）
no Go files in /home/runner/work/homeagentsdk/homeagentsdk
`go build .` 缺 `working-directory: tools/hmapdev`，于是在仓库根执行 ——
根目录没有 Go 文件（包在 sdk/ 子目录）。加 working-directory 后本地实测
linux/arm64、darwin/arm64、windows/amd64 均产出 27–30MB 二进制。
## 2. Examples：装了 Go 1.21，而 examples 要求 1.25
go: go.mod requires go >= 1.25.0 (running go 1.21.0; GOTOOLCHAIN=local)
`go-version-file: go.mod` 读的是**根** go.mod —— 它写 `go 1.21.0`，
而 20 个 `example/*/go.mod` 都要求 `go 1.25.0`（只有根与 tools/hmapdev 是 1.21）。
于是 CI 装 1.21，examples 构建必失败。
★ 为什么本地测不出来：本机 Go 1.27 且 GOTOOLCHAIN 默认可自动取更高工具链，
更高版本能满足 1.25 的下限，所以一路通过。而 GitHub runner 上
**GOTOOLCHAIN=local**，Go 拒绝自动下载工具链，低版本直接报错。
本地「能过」在这里完全不构成证据。
改法：SDK CI 全部钉 `go-version: '1.25'`（同时满足 1.21 的下限与
examples 的 1.25 要求）。
## 3. 技能检查：hmapdev 建到了 /tmp
error: no active SDK version set
`resolveSkillsSource()` 先用**可执行文件位置**向上找仓库
（tools/hmapdev → ../../skills），落空才回退到 SDK store 的活跃版本。
我把二进制建到 /tmp/hmapdev ⇒ 推出仓库失败 ⇒ 回退 ⇒ CI 里没有 store ⇒ 报错。
改法：建到仓库内 `<repo>/build/hmapdev_ci`。本地实测（构建在仓库内时，
即便从 /tmp 调用也能正确识别仓库源——解析依据是 exe 位置而非 cwd）。
## 附带记录
- 根 go.mod(1.21) 与 example/*/go.mod(1.25) 的版本不一致本身值得关注：
用 Go 1.22–1.24 的用户按示例走会失败。是否统一属产品决策，本次不动。
- actionlint 全绿。
|
2026-09-29 15:29:16 +08:00 |
|
|
|
5759e58bad
|
ci: 建立 CI —— 此前 main 的推送与 PR 完全没有检查
## 缺口
本仓此前**只有 release.yml**（只在 release/** 推送时跑）。也就是说
推 main、开 PR 一律无检查，而 SDK 正是外部插件开发者直接依赖的契约面
（sdk/plugin.go 接口一破，所有外部插件编译失败）。
## 四个 job（每条命令都本地实测过）
| job | 内容 | 实测耗时 |
|---|---|---|
| go | 根模块 build + vet + test | <1s |
| hmapdev | 嵌套 module 测试 + 五平台交叉编译（矩阵） | ~2s + 编译 |
| examples | 构建全部 20 个示例（linux/amd64、darwin/arm64） | 9s / 21s |
| consistency | Lua SDK 三副本一致 + skills 可识别 + mkdocs --strict | ~2s |
## 三处「不能想当然」的地方（都有实测依据）
1. **示例不能用 `go build` 验**。它们是插件（只有 plugin.go、没有 func main），
必须由 hmapdev 注入 main 包装；直接 go build 得到
"function main is undeclared in the main package" —— 那不是缺陷，是方式不对。
故与发版走**同一个脚本**（package/build-examples.sh），避免 CI 与发版路径分叉。
2. **tools/hmapdev 是独立 module**，根模块的 `go test ./...` 不会进入它 ——
必须单独跑，否则它的测试永远不在 CI 里执行（Go 的模块边界）。
3. **不能用 `yaml.safe_load` 校验 mkdocs.yml**：它含 mkdocs-material 的
`!!python/name:` 标签（配置 emoji 的官方写法），safe_load 报
ConstructorError —— 是校验方式不对。改用 `mkdocs build --strict`
（本地实测 2s、0 warning）。
## 明确不进 CI
- `hmapdev skill install` —— 它会写开发者本机的 ~/.claude、~/.codex 等目录
- 需要内核仓在场的检查（本仓独立可测）
- 任何网络/真机依赖
CGO_ENABLED=0（SDK 纯 Go，与主仓相反）。
actionlint 全绿（修掉一处 shellcheck SC2012）。
|
2026-09-29 15:18:58 +08:00 |
|
