homeagent-sdk

jianf/homeagent-sdk

Fork 0

mirror of https://gitcode.com/JianFeeeee/homeagent-sdk.git synced 2026-10-31 06:17:25 +00:00

Commit Graph

Author SHA1 Message Date

Author	SHA1	Message	Date
JianFeeeee	e82d21d633	fix(ci): 发版前校验分支名与 meta.Version 一致（防开发阶段误发版） ## 事故（2026-10-17） `release.yml` 的触发条件是 `push: branches: ['release/']`，而 tag 名 = `v` + `meta.Version`。于是： 2026-10-17 08:35 github-actions[bot] 打出 v1.4.0 并发布 Release 而 1.4.0 当时是开发阶段。起因只是有人（我）为了走 PR 流程建了一个 release/v1.4.x 分支并推送 —— 那一刻就自动发版了。更麻烦的是它钉在旧提交 `c2474f5` 上：之后又合了三个修复（异步投递、台账回填、示例 go.mod 修复），已发布的 1.4.0 里没有** 这些修复，而 Release 页面看起来是"最新"。已按要求撤掉该 tag 与 Release。 ## 改动 `prepare` 阶段在读出 meta.Version 之后，校验分支名： release/vX.Y.x → meta 必须是 X.Y.* （中版本长跑线） release/vX.Y.Z → meta 必须恰好 X.Y.Z 不一致直接 exit 1，并提示"开发阶段请勿推 release/"。 ## 判据（2 条） · `TestReleaseWorkflowGuardsVersionMismatch`：逐形态断言两个分支形态都有拒绝逻辑 + 有 exit 1 · `TestNoStaleReleaseTagForDevVersion`：记录当前 meta.Version 是开发版本 ★ 判据写砸过一次并修好：第一版用 `if !contains(A) && !contains(B) { fail }` —— 删掉其中任意一处描述文案，另一处还在，判据仍通过 ⇒ 变异不咬。改为逐形态断言**后，两个变异都准确报出是哪个形态缺保护。	2026-10-18 08:05:32 +08:00
JianFeeeee	56c694cd7c	ci: gh release download 需显式 --repo 回读校验先 cd /tmp/back（非 git 目录），而 gh 默认从当前目录的 git 上下文推断仓库，于是报 "not a git repository" —— 发布本身成功（tag/release/附件齐全），却被这道校验误判为失败。改为 gh release download "$TAG" --repo "$GITHUB_REPOSITORY"。	2026-09-29 14:39:12 +08:00
JianFeeeee	dc9e7d0495	ci: SDK 仓发布流水线 —— release/ 推送即出 hmapdev 五平台产物与主仓 Release 流水线同构，差异只在产物与打包命令： prepare 读 meta.Version；tag 已存在则整轮跳过；go test 门可显式跳过（改 meta 的提交里写 [skip-release-tests]，查该提交而非 HEAD） build go build（硬门）→ go test → build.sh all hmapdev → 验证 5 平台齐全 → 生成 SHA256SUMS → artifact publish 打 tag → gh release create 传附件 → 回读校验 sync-gitcode 有 GITCODE_TOKEN 时同步（无则跳过）产物清单不是猜的，依 gitcode 上 v1.2.0/v1.3.0 的实际附件（各 6 个）： hmapdev_{linux,darwin}_{amd64,arm64} + hmapdev_windows_amd64.exe + SHA256SUMS 两个易错点都有实测依据： 1. 测试要分两处跑：tools/hmapdev 是独立 module，根模块的 `go test ./...` 不会进入它（Go 的模块边界，不是配置问题）。 2. gitcode 上传必须显式列文件名：上传脚本的路径语义是 `os.path.join(ASSET_DIR, name)`，所以要 cd 进目录 + `ASSET_DIR=.` + 裸名；而它按扩展名识别产物的默认扫描对 hmapdev 无效** —— 五个产物里只有 windows 那个有扩展名，自动扫描会静默地一个都不传。故把主仓的 upload_assets.py 一并纳入本仓 scripts/（两仓各自独立可取）。本地已验证：`VERSION=1.4.0 bash package/build.sh all hmapdev` 产出 5 个二进制（各 27–29M），根模块 go test 通过，actionlint 全绿。	2026-09-29 14:09:35 +08:00

JianFeeeee

e82d21d633

fix(ci): 发版前校验分支名与 meta.Version 一致（防开发阶段误发版）

## 事故（2026-10-17）

`release.yml` 的触发条件是 `push: branches: ['release/**']`，
而 tag 名 = `v` + `meta.Version`。于是：

	2026-10-17 08:35  github-actions[bot] 打出 v1.4.0 并发布 Release

而 1.4.0 当时是**开发阶段**。起因只是有人（我）为了走 PR 流程建了一个
release/v1.4.x 分支并推送 —— 那一刻就自动发版了。

更麻烦的是它钉在旧提交 c2474f5 上：之后又合了三个修复
（异步投递、台账回填、示例 go.mod 修复），已发布的 1.4.0 里**没有**
这些修复，而 Release 页面看起来是"最新"。已按要求撤掉该 tag 与 Release。

## 改动

`prepare` 阶段在读出 meta.Version 之后，校验分支名：

	release/vX.Y.x  → meta 必须是 X.Y.*   （中版本长跑线）
	release/vX.Y.Z  → meta 必须恰好 X.Y.Z

不一致直接 exit 1，并提示"开发阶段请勿推 release/**"。

## 判据（2 条）

 · `TestReleaseWorkflowGuardsVersionMismatch`：逐形态断言两个分支形态
   都有拒绝逻辑 + 有 exit 1
 · `TestNoStaleReleaseTagForDevVersion`：记录当前 meta.Version 是开发版本

★ 判据写砸过一次并修好：第一版用
    `if !contains(A) && !contains(B) { fail }`
  —— 删掉其中任意一处描述文案，另一处还在，判据仍通过 ⇒ 变异不咬。
  改为**逐形态断言**后，两个变异都准确报出是哪个形态缺保护。

2026-10-18 08:05:32 +08:00

JianFeeeee

56c694cd7c

ci: gh release download 需显式 --repo

回读校验先 cd /tmp/back（非 git 目录），而 gh 默认从当前目录的
git 上下文推断仓库，于是报 "not a git repository" —— 发布本身
成功（tag/release/附件齐全），却被这道校验误判为失败。

改为 gh release download "$TAG" --repo "$GITHUB_REPOSITORY"。

2026-09-29 14:39:12 +08:00

JianFeeeee

dc9e7d0495

ci: SDK 仓发布流水线 —— release/** 推送即出 hmapdev 五平台产物

与主仓 Release 流水线同构，差异只在产物与打包命令：

  prepare  读 meta.Version；tag 已存在则整轮跳过；go test 门可显式跳过
           （改 meta 的提交里写 [skip-release-tests]，查该提交而非 HEAD）
  build    go build（硬门）→ go test → build.sh all hmapdev → 验证 5 平台齐全
           → 生成 SHA256SUMS → artifact
  publish  打 tag → gh release create 传附件 → 回读校验
  sync-gitcode  有 GITCODE_TOKEN 时同步（无则跳过）

产物清单不是猜的，依 gitcode 上 v1.2.0/v1.3.0 的实际附件（各 6 个）：
  hmapdev_{linux,darwin}_{amd64,arm64} + hmapdev_windows_amd64.exe + SHA256SUMS

两个易错点都有实测依据：

1. **测试要分两处跑**：tools/hmapdev 是**独立 module**，根模块的
   `go test ./...` 不会进入它（Go 的模块边界，不是配置问题）。
2. **gitcode 上传必须显式列文件名**：上传脚本的路径语义是
   `os.path.join(ASSET_DIR, name)`，所以要 cd 进目录 + `ASSET_DIR=.` + 裸名；
   而它按扩展名识别产物的默认扫描对 hmapdev **无效** —— 五个产物里只有
   windows 那个有扩展名，自动扫描会静默地一个都不传。
   故把主仓的 upload_assets.py 一并纳入本仓 scripts/（两仓各自独立可取）。

本地已验证：`VERSION=1.4.0 bash package/build.sh all hmapdev` 产出 5 个
二进制（各 27–29M），根模块 go test 通过，actionlint 全绿。

2026-09-29 14:09:35 +08:00

3 Commits