From 8910c8c454a370c30cf51ca33b28f4b7754d3843 Mon Sep 17 00:00:00 2001 From: JianFeeeee Date: Sun, 13 Sep 2026 18:23:22 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E8=A1=A5=E4=B8=A4=E6=9D=A1=E6=B5=81?= =?UTF-8?q?=E6=B0=B4=E7=BA=BF=E7=BA=AA=E5=BE=8B=EF=BC=88=E8=84=9A=E6=9C=AC?= =?UTF-8?q?=E5=BF=85=E9=A1=BB=20set=20-e=EF=BC=9Btag=20worktree=20?= =?UTF-8?q?=E9=87=8C=E7=9A=84=E9=A9=B1=E5=8A=A8=E8=84=9A=E6=9C=AC=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 今天连踩两次，都是"脚本本身"的问题而不是打包逻辑的问题： 1. **没 `set -e`**：`package-windows.sh` 在 tag worktree 里找不到（新脚本只在 main）， bash 报 No such file or directory 之后**流程照旧往下走**，把只含 4 项的校验和 传上去覆盖了原本覆盖 10 项的那份 ⇒ 只能把产物下回来重建。 2. **驱动脚本不在 tag 里**：发布件在 tag 的干净 worktree 里构建，而刚补的脚本还没进 tag。 ⇒ 让脚本支持 `DIST_LINUX` / `BUILD_DIR` / `DIST_RELEASE` 覆盖，用"主仓脚本 + 产物目录 指向 worktree"来解；文档写清这条约束。 同步进发布技能的同名小节（这两条和"分批上传要全量重算校验和"是同一类：**校验和的完整性 比产物本身更容易被流程吃掉**）。 --- docs/git-branching.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/git-branching.md b/docs/git-branching.md index d362897..3bf75eb 100644 --- a/docs/git-branching.md +++ b/docs/git-branching.md @@ -414,6 +414,13 @@ GITCODE_REPO=JianFeeeee/homeagent-sdk ASSET_DIR=/dist/release \ - 脚本先向 `releases//upload_url` 取 **OBS 预签名 URL** 再 PUT ⇒ **release 条目必须先存在**； - alpha/beta 的产物可以上传，但必须在 release 条目上勾选**预发布**标志（§2.4）； - 校验和必须覆盖**全部**附件，否则等于没有校验。 +- ❗**流水线脚本必须 `set -e`（或显式检查每步）**：否则某一步失败（例如驱动脚本在 tag 里 + 不存在）之后它仍会继续跑到上传，把**半成品校验和**推上去覆盖全量的那份。 + （实测：v1.3.10 的校验和被 4 项覆盖掉，只能重建。） +- ❗**在 tag 的 worktree 里构建时，驱动脚本要么已进该 tag，要么支持目录覆盖**： + 新补的脚本只存在于 main，去 tag 的 worktree 里调就是 `No such file or directory`。 + 现 `package-windows.sh` 支持 `DIST_LINUX` / `BUILD_DIR` / `DIST_RELEASE` 覆盖， + 可以"用主仓的脚本 + 产物目录指向 worktree"。 - ❗**分批上传时，后一轮必须在全量产物上重算 `SHA256SUMS`**，不能只算本轮那几个文件： 同名附件会**覆盖**前一轮的校验和（实测：先传 amd64 的 9 个资产，后补 arm64 时 只算了 arm64 的 4 个，结果 amd64 的校验和从 release 上消失 ⇒ 已下载的包失去校验依据，