jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-11-01 14:57:38 +00:00
Code Issues Packages Projects Releases Wiki Activity
889 Commits 5 Branches 29 Tags
49141fe6f061765b72eb3345f6052efe31bbad6d
Commit Graph

7 Commits

Author SHA1 Message Date
supervisor
a3ab6e5cfa docs(deploy): SDK 镜像仓示例统一为 hologramagentsdk 
upload_assets.py docstring 与 docs/git-branching.md 的上传示例里，SDK 仓
仍写 homeagent-sdk；按已定口径（SDK 仓名 hologramagentsdk，gitcode/GitHub
两侧均 200 实测）统一，避免与 sdk-docs 线合并后出现两种说法。

纯注释/文档改动，零代码逻辑变更。
 2026-10-21 20:18:30 +08:00
JianFeeeee
ffe9bc2cff refactor(ci,docs): gitcode 镜像仓改名 HomeAgent→HologramAgent，定义点取值对齐 
gitcode 侧镜像仓已完成改名，旧名 HomeAgent 变成 301 跳转，真仓是
HologramAgent。dbb787a 里三处 GC_REPO 定义点仍取旧名（命中 301），本批只
改取值与说明，**不改变 dbb787a 已建立的「每个文件恰一个定义点」结构**，
不引入任何新字面量。

实测（2026-10-21 20:1x，直连不带代理，非推测）：
  $ curl -s -o /dev/null -w '%{http_code}' https://gitcode.com/JianFeeeee/<repo>

  HologramAgent     → 200  ← 当前取值
  HomeAgent         → 301  ← 旧名，跳转到 HologramAgent
  homeagent-sdk     → 200（SDK 仓，另一对象）
  hologramagentsdk  → 200（SDK 仓，另一对象）
  homeagentsdk      → 404
  HologramAgent-sdk → 404

「301 不是另一个仓，就是同一仓改名」的判定依据：两个地址 `git ls-remote`
得到的 refs 列表 md5 相同（同一组分支与 SHA），且 curl 页面 title 一致。

三个定义点（各文件恰好 1 处，消费点全部走变量，本次只改这三行的取值）：
1. .github/workflows/ci.yml   job sync-gitcode-main 的 env.GC_REPO
2. .github/workflows/release.yml job sync-gitcode   的 env.GC_REPO
3. deploy/scripts/upload_assets.py 的 os.environ.get("GITCODE_REPO", ...) 默认值
消费点未动：ci.yml 2 处、release.yml 4 处命令行，仍全部是 ${GC_REPO}。

注释同步改准（原来把 301 的仓写成「200 ← 当前用这个」，是错的）：
- 两个 workflow 的取值依据清单换成上面六个仓的现状，注明实测时间与 curl 命令
- 明确 HomeAgent = 301 跳转、HologramAgent = 当前取值
- 「以后再改名只改这三行」的说明保留

docs/zh/ci-cd-runbook.md 同步：
- 总览表 gitcode 镜像改为 HologramAgent（与主仓同名）
- 「当前取值」段与六仓实测表、301 判定依据
- API 侧口径也改准：/api/v5/repos/JianFeeeee/{HomeAgent,HologramAgent}
  不带 token 均 400（需鉴权，非仓不存在）；/releases/tags/v1.3.13
  两名字均 200 且响应体一致。旧文档写「HologramAgent→404 是死链」已不成立。
- §3.3 curl 验活地址、§3.4 手工上传示例的 GITCODE_REPO 同步为新值

判据（正向 14 项 + 变异 11 条，全部实跑）：
- 两个 workflow yaml.safe_load 解析通过；每个 env.GC_REPO 恰好 1 处
- 三处定义点取值完全一致（P4）；消费点计数 ci=2/release=4（P6）
- P8 改为「不带 -L 的 200」：这正是本次误判的根因——之前用 curl -L 测，
  301 跟随后也是 200，把「旧名跳转」误读成「旧名是真仓、新名 404」
- 变异 M11「三处一致改回旧名 HomeAgent」只被 P8 抓住（P4 仍绿），
  证明该判据能单独区分「一致但指向 301 旧名」
- 所有 step run 块过 bash -n（30 个 run 块，0 错）
- gitcode 作 import host 残留 0；工作区无 .go/.lua/go.mod/go.sum 变更

零代码改动：packaging_test.go 里「禁止历史模块路径」的反向断言未动，
third_party 未动，systemd 相关行未动。
 2026-10-21 20:15:41 +08:00
JianFeeeee
dbb787a658 refactor(ci,docs): gitcode 镜像仓名收为单一定义点，取值 HomeAgent（实测 200） 
gitcode 镜像目标仓名此前在 3 个文件里各写死多份字面量，改名时要遍改且极
易漏（漏一处 = 一个静默死链，而且失败面在 release 里只有一格）。本批只做
「收成单点」，不改任何取值、不碰代码。

三个定义点（每个文件恰好 1 处，消费点全部走变量）：
1. .github/workflows/ci.yml → job `sync-gitcode-main` 的 env.GC_REPO:232
   消费点 2 处命令行：git ls-remote 探测、git push main。
2. .github/workflows/release.yml → job `sync-gitcode` 的 env.GC_REPO:375
   消费点 4 处命令行：git ls-remote 探测、push tag、POST /releases、
   upload_assets.py 的 GITCODE_REPO 传入。
   （两个 workflow 是独立文件，不能共享 env，故各自一处定义。）
3. deploy/scripts/upload_assets.py → os.environ.get("GITCODE_REPO", ...) 默认值。
   手工跑脚本时的兜底，与两个 workflow 同值。

为什么取值 JianFeeeee/HomeAgent 而不是 HologramAgent：
GitHub 主仓已改名 HologramAgent，但 **gitcode 侧镜像仓没有跟着改名**。
curl 直连实测（2026-10-21）：
  https://gitcode.com/JianFeeeee/HomeAgent      → 200   ← 当前取值
  https://gitcode.com/JianFeeeee/HologramAgent  → 404
指向 HologramAgent 会让每次发版/推 main 都在镜像同步这步红掉，且国内镜像
停止更新。

两个 job 的失败面不同（容易搞混，此处写明）：
- release.yml 的 sync-gitcode：needs [prepare, publish]。探测 exit 1 ⇒
  **只红「镜像同步」这一格**；GitHub 侧 release 产物已经发出去了。
- ci.yml 的 sync-gitcode-main：needs [go, race, cross, gui, csrc, docs] 全绿
  后才跑。探测 exit 1 ⇒ **main 的整条 CI 红**（不是一格）。
所以仓名写错的真实后果是「必红一格 + 国内镜像不更新」，不是「发不出包」。

何时切回 HologramAgent：等 gitcode 上把镜像仓真正改名/新建成功、
https://gitcode.com/JianFeeeee/HologramAgent 返回 200 之后，
**只改上面这三行**即可，两个 workflow 的消费点与 runbook 均无需再动。

docs/zh/ci-cd-runbook.md 同步三节：单点化表格（定义处/消费点）、当前取值与
200/404 实测依据、两个 job 的失败面差异；并把 §3.4 的 curl 验活地址与
upload_assets 手工调用示例同步到 HomeAgent（原写法是已 404 的死链）。

判据（含变异，全部实跑）：
- 两个 workflow 可被 yaml.safe_load 解析；每个 jobs[..].env.GC_REPO 恰好 1 处
- 每个 step 的 run 块抽出来喂 bash -n，全部无语法错
- 可执行形态里的 gitcode 目标仓名不含 HologramAgent（注释行豁免）
- 变异：把任一 GC_REPO 定义改回 HologramAgent、或把某消费点还原成字面量，
  判据均报红
- 零代码改动：git status 无 .go/.lua/go.mod/go.sum；go build ./... 通过
 2026-10-21 19:55:59 +08:00
JianFeeeee
228fae252d fix(docs): 回退 PLUGIN_DEV 的 SDK import 示例，并修正 upload_assets/gui homepage 的仓名 
上一批 37b8c26 把文档里 4 处 Go import 示例改成了
`github.com/JianFeeeee/HologramAgent-sdk/sdk`，但该 module 路径并不存在：
主仓 go.mod:16 仍是 `github.com/JianFeeeee/homeagentsdk v0.9.2`，:46 replace
目标未变，third_party/homeagent-sdk/go.mod 首行仍是
`module github.com/JianFeeeee/homeagentsdk`，GitHub 上 HologramAgent-sdk
与 hologramagentsdk 均 404。照着文档抄这行 import 会直接 module not found，
比不改更坏。本次回退成真实可编译的 homeagentsdk。

改动：
- assets/docs/{zh,en}/PLUGIN_DEV.md 各 2 处（zh:253、448；en:255、455）
  import 路径回退为 github.com/JianFeeeee/homeagentsdk/sdk。该行附近未加任何
  「已改名」说明——等 SDK 仓真改名、主仓 go.mod 与第三方 module 一起改时
  再统一处理，属另一批。全仓已无 HologramAgent-sdk/sdk 形态。
- deploy/scripts/upload_assets.py:8、:23 默认目标仓
  JianFeeeee/HomeAgent → JianFeeeee/HologramAgent（主仓确已改名，HomeAgent
  在 GitHub 上 301）。:8 括号里「SDK 仓传 JianFeeeee/homeagent-sdk」按要求保留。
- cmd/gui/package.json:5 homepage 元数据同步为 HologramAgent；该文件仅此
  1 行变更，name/author/description 等其它字段未动。

保留不动（已获确认属正确形态）：
- go.mod 两行与 deploy/packaging/package-linux.sh 六处 homeagentsdk
  （必须与 go.mod 逐字一致）
- internal/**/*.go 的 74 处真实依赖 import
- deploy/packaging/packaging_test.go:99,101 对 gitcode.com/JianFeeeee/HomeAgent
  的反向断言（它断言 build.sh 不得使用历史路径）
- internal/plugins/webui 三处注释里的 homeagent.jianfgit.xyz（历史实测记录）
- cd HologramAgent-sdk / clone ...HologramAgent-sdk.git（操作指令目录名与 URL，
  非 import 路径）

判据：7 条正向（含「文档 import 路径必须与 go.mod 的 SDK module 同源」）；
变异 4 次均按预期报红——分别还原 zh:253 import、upload_assets.py:23 默认值、
gui homepage、以及把 packaging_test.go 反向断言那两行也改名。
go build ./... 通过，go test ./deploy/packaging/ 通过。
 2026-10-21 19:25:05 +08:00
JianFeeeee
e188296dab fix(release): .hmap 纳入发布产物白名单 + 路径解析 
## 白名单（真问题）

`upload_assets.py` 的 ARTIFACT_SUFFIXES 只有 .tar.gz/.zip/.deb/.rpm/.pkg/_win64.exe，
**没有 .hmap** —— 即使插件包已经构建好放在 dist/ 下，上传时也会被静默跳过。
这正是「release 里一个插件包都没有」的直接原因之一。

补 `.hmap` 与 `SHA256SUMS.plugins`（插件包的汇总校验和，与内核包的 SHA256SUMS 分开，
避免混用）。实测 is_artifact() 现能正确识别两者、仍跳过 README.md。

## 测试路径解析

`HMAP_BUNDLE_DIR=dist/plugins` 这种相对仓根的写法原先会失败：测试的 cwd 是包目录
（internal/plugins/pluginmgr），相对路径解析到包内，报 "no such file or directory"，
看起来像产物不存在。改为相对路径按仓根解析（向上找含 go.mod 的目录）。

实测三种调用都正确：相对路径、绝对路径、不设时 skip。
 2026-09-20 09:07:33 +08:00
JianFeeeee
8e2b27f072 fix(release): upload_assets.py 按 go.mod 定位仓库根，不再数 dirname 
脚本从 scripts/ 移到 deploy/scripts/ 后目录深度 1→2，而两层 dirname
是写死的，于是资产目录解析成 deploy/dist/release，上传直接
FileNotFoundError（v1.0.1 首次上传即因此失败）。

这与 v0.7.2 的 7f08f3c 把 package/ 移到 deploy/packaging/ 打断
build.sh 的 PROJECT_ROOT 是同一个坑：目录搬家没更新相对路径。改成
向上找 go.mod，以后脚本放哪都不会错。

顺带把两个静默失败改为显式报错：目录不存在、目录下无可识别产物
（原先前者抛裸 FileNotFoundError，后者会打出 ALL OK 却一个都没传）。
 2026-09-04 10:34:51 +08:00
JianFeeeee
d043fed5ce docs: 文档与发布脚本同步到 v1.0.0 子进程架构 
README/架构文档仍在描述 C ABI 动态库加载，与 v1.0.0 实际实现不符。
新用户按文档走会去做 -buildmode=c-shared，产物新内核根本不加载。

README.md / README_EN.md：
- 设计要点补子进程架构段（三面通信、崩溃自愈、真热重载）
- 代码结构 plugin/ 描述：.so 动态加载器 → 子进程加载器
- 项目状态补 v1.0.0 条目（6 类缺陷 + 实测数字），v0.9.0 标注 ABI 已退场
- 新增「下载」章节：三变体对照 + 各平台包格式 + macOS 限制

assets/docs/{zh,en}/ARCHITECTURE.md：
- 四种加载方式表：外部 .so/C ABI → 外部子进程/握手+stdio JSON-RPC
- 加载流程改写为 exec.Command → 继承 fd → 握手 → init → start
- 内置 vs 外部对照表 7 行更新
- 新增「子进程插件的三个通信面」小节，含每个面的选择理由

assets/docs/{zh,en}/OVERVIEW.md：插件系统段落改写

deploy/ 发布脚本三处回归（v0.7.2 的 7f08f3c 把 package/ 移到
deploy/packaging/ 使目录深度 1→2，但没改相对路径，此后两个版本
的发布都没有二进制资产）：
- build.sh：.syso 按目标平台 hide/restore（trap 兜底），恢复
  windows 目标的 CXX，arm64 刻意不带 CXX
- installer.nsi：5 处 ..\build → ..\..\build，PRODUCT_VERSION 可注入
  （原先硬编码 0.8.0）
- homeagent.spec：server 变体补装 waiter（control-server 声明了 CLI 却没装）

deploy/scripts/upload_assets.py：release 资产上传（两步签名 URL → OBS
PUT）。放 deploy/scripts/ 而非 scripts/，因为后者在 .gitignore 里。
支持 GITCODE_REPO/ASSET_DIR 环境变量以复用于 SDK 仓。
 2026-09-03 19:26:17 +08:00