Skip to content

fix(ci): tag 发布时创建 GitHub Release 并触发独立版打包 - #37

Closed
HerbertGao wants to merge 6 commits into
studyzy:mainfrom
HerbertGao:fix/standalone-github-release
Closed

HerbertGao wants to merge 6 commits into
studyzy:mainfrom
HerbertGao:fix/standalone-github-release

Conversation

@HerbertGao

Copy link
Copy Markdown

Closes #36

问题

openspec-cn install 只认带 SHA256SUMS 的 GitHub Release。本仓库的 scripts/binary/ 和 binaries.yml 已经从上游同步,但发布时没有创建 Release,所以上传 job 从未运行。

release-prepare.yml 仍要求 github.repository == 'Fission-AI/OpenSpec',在本仓库每次推送 main 都会 skip。实际发布入口是 tag 推送的 release.yml,它只发 npm。

改动

tag 推送时增加一个独立 job:

  1. 若该 tag 还没有 GitHub Release,就创建。带 - 的 tag 标为 prerelease,避免盖过 Latest。
  2. workflow_dispatch 已有的 binaries.yml,传入这个 tag。

用 GITHUB_TOKEN 创建的 Release 不会触发其他 workflow,所以不能只靠 gh release create。workflow_dispatch 是这个 token 可以触发的例外,binaries.yml 也已经接受 tag 输入。

没有改 release-prepare.yml。把它的仓库条件改过来会在每次推送 main 时运行 changesets,并依赖上游的 GitHub App 和 npm OIDC;这个仓库的发布路径是 NPM_TOKEN 加 tag。

合并后

这个 workflow 随被推送的 tag 走。合并后需要再推一个包含本次提交的 tag,独立版文件才会出现。远程目前没有 v1.15.0 tag。已有旧 tag 不会自动补文件。

仓库的 Actions 权限需要允许 GITHUB_TOKEN 写 contents 并触发 workflow。如果组织把 token 限制为只读,这个 job 会失败。

未验证

没有在本仓库触发 tag 发布,也没有实际跑 bun scripts/binary/build.mjs。

release-prepare.yml 仍只在 Fission-AI/OpenSpec 上运行,不会创建 Release。
GITHUB_TOKEN 创建的 Release 不会触发其他 workflow,因此显式 dispatch binaries.yml。
workflow_dispatch 只是排队,发布 job 会在 SHA256SUMS 出现前成功。
改为调用 binaries.yml;已有完整 Release 则跳过。
全角括号紧挨 $asset 时,bash 3.2 会把它算进变量名。
"$releases.atom" 在 PowerShell 里是取属性,不是拼 .atom。
PowerShell 7 对非文本类型的 atom 响应返回 byte[],正则匹配不到标签。
本地发布列表按原始字节读取,避免 PowerShell 7 把 atom 当成字节数组。
测试改为按 UTF-8 读取安装脚本,并给 install.ps1 加上 BOM。
@studyzy

studyzy commented Nov 1, 2026

Copy link
Copy Markdown
Owner

@copilot resolve the merge conflicts in this pull request

studyzy added a commit that referenced this pull request Nov 1, 2026
`"$releases.atom"` 是字符串的属性查找,取到空值,feed 等于没读到;
改用 `${releases}.atom` 之后,`.Content` 又因为是 atom+xml 返回
byte[],正则匹配不到任何标签,最终报「未找到包含独立版文件的发布版」。

改为先 -OutFile 落盘再按 UTF-8 读文本,两条路径都绕开。

Refs #37
studyzy added a commit that referenced this pull request Nov 1, 2026
* fix(install): 变量名后紧跟全角字符时加花括号

macOS 自带的 bash 3.2 会把紧跟变量的 UTF-8 首字节并进变量名,
`"$file("` 因此读的是 `$file(` 这个空变量。下载地址于是变成
`.../download/v1.2.0/`,真机安装直接 404。

dash/sh 不受影响,所以这个问题只在 macOS 和 bash 构建里出现。

同处 PowerShell 用 `${releases}.atom`,否则被当成字符串的属性查找。

Refs #37

* fix(install): PowerShell 7 把 atom feed 当字节数组读

`"$releases.atom"` 是字符串的属性查找,取到空值,feed 等于没读到;
改用 `${releases}.atom` 之后,`.Content` 又因为是 atom+xml 返回
byte[],正则匹配不到任何标签,最终报「未找到包含独立版文件的发布版」。

改为先 -OutFile 落盘再按 UTF-8 读文本,两条路径都绕开。

Refs #37
@studyzy

studyzy commented Nov 1, 2026

Copy link
Copy Markdown
Owner

安装脚本那部分已经单独合入 main(#38),这里说一下剩下的事。

CI 里真正红的

linux-bash / linux-bash-node22 / linux-bash-node24 / macos-bash 全部是同一个 bug:

echo "正在下载 $file($version)..."   # macOS bash 3.2 把全角「(」的首字节并进变量名

读的是空变量 $file(,URL 变成 .../download/v1.2.0/,404。你在 fix(install): 避免 macOS bash 和 PowerShell 把变量名读断 里修过一次,但最后的 merge commit 又把它退回成 $file 了。已按你的花括号方案修好并合入。

install.ps1 那行 "$releases.atom" 也一起修了($ 后跟点号是属性查找)。不过只加花括号还不够:PowerShell 7 对该 feed 返回 byte[],正则匹配不到标签,所以改成 -OutFile 落盘再按 UTF-8 读文本。

Dependency Review 那条是仓库没开 Dependency graph,跟代码无关。

这个 PR 需要先解决的问题

release.yml 这条链路在本仓库一次都没成功跑过,我没法在 CI 里验证它会工作:

  • gh release list 为空,release.yml 在 tag push 下的历史运行为 0 次。
  • PR 上 Binaries 的每次运行都是 0 秒失败,取不到任何日志。
  • 另外 Verify windows-x64 / Verify windows-arm64 在本仓库历史上从未通过(同一 Install script (Windows) 步骤,powershell 5.1 的 fallback 用例),和这条链路无关,但会一直挂着红。

建议:workflow_call 换成 workflow_dispatch 触发 binaries.yml 并用 API 轮询结果,先在 studyzy/OpenSpec-cn 上真跑一次 tag 发布,把 Binaries 和 Release 跑绿,再合入建 Release 的逻辑。需要的话我可以接着做。

@studyzy

studyzy commented Nov 1, 2026

Copy link
Copy Markdown
Owner

关闭这个 PR。这里有价值的部分已经全部合入 main,剩下的既无法验证也没修好对应问题。说明一下结论,避免以后翻历史时误判。

一、哪些已经进了 main

安装脚本的修复单独走了 #38,已合入(c5c92aec):

  • install.sh:变量名后用全角括号时加花括号。macOS bash 3.2 会把紧跟的全角「(」的 UTF-8 首字节并进变量名,$file( 因此读到空值,下载地址变成 .../download/v1.2.0/,真机安装 404。这也是 CI 里 linux-bash / linux-bash-node22 / linux-bash-node24 / macos-bash 四条腿同时红的原因。
  • install.ps1:除了 "$releases.atom" 是属性查找(应为 "${releases}.atom"),还需要改成 -OutFile 落盘再按 UTF-8 读文本——PowerShell 7 对该 feed 返回 byte[],正则匹配不到任何标签。

#38 上这四条腿全部转绿,All checks passed 通过。因此本 PR 对 install.sh / install.ps1 的改动已被 main 取代,现在这两处也构成合并冲突。

二、哪些没有合入,为什么

binaries.yml 的 Windows 测试改写:没有独立价值

Invoke-Installer 那套改写对应的正是 Verify windows-* 长期失败的步骤,但在这个 PR 自己的运行里它仍未通过:

  • 运行 40308458906 的 Verify windows-x64,Install script (Windows) 步骤失败;
  • 卡点仍是 fallback 用例(powershell 5.1 下的回退安装),和改写前一致。

改写了测试,但没有修好这个测试要验证的路径。因此这部分拿不出来独立合入。

release.yml 的发布链路:无法验证,需要先真跑一次

思路(tag push 时建 Release,再调 binaries.yml)本身是合理的,(inputs.tag || '') != '' 这个补丁也确实是必需的,否则 reusable 调用下 attach job 会被静默跳过。

但在本仓库它一次都没成功运行过:

  • gh release list 为空;
  • release.yml 在 tag push 下的历史运行为 0 次;
  • 本 PR 上 Binaries 的每次运行都是 0 秒失败,取不到任何日志。

没有一次真实运行的证据,就不宜合入一条会动发布链路的改动。建议另起 PR,从干净基线开始,并且先在 studyzy/OpenSpec-cn 上真跑一遍 tag 发布再合。

三、后续怎么做

  1. 发布链路另开 PR。建议先用 workflow_dispatch 触发 binaries.yml + API 轮询结果,确认整条链路能跑通,再换回 workflow_call 或保留轮询发案。
  2. 推一个包含修复的 tag,实际观察 Release / Binaries 两个 workflow 的表现。本仓库远程目前没有 v1.16.0 标签。
  3. Windows 的 Verify windows-* 是既有问题,与本 PR 无关,历史上从未通过。它在 main 上会一直挂着红,可以单独排查 powershell 5.1 的 fallback 路径。
  4. Dependency Review 的报错是仓库没开启 Dependency graph,和代码无关:Settings → Code security 打开即可。

感谢 @HerbertGao 的排查,安装脚本那个 bash 3.2 的变量名问题定位得很准,那部分已经落地了。

@studyzy studyzy closed this Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

openspec-cn install 失败:没有带独立版文件的 GitHub Release

2 participants