Repository navigation
ci(release): tag 推送后自动补鸿蒙与 Linux 包 - #1273
Merged
H-Chris233 merged 5 commits intoOct 27, 2026
Merged
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
`Release HarmonyOS` 与 `Release Linux egui` 原本是 dispatch-only，但没有任何东西 把它们和 `v*-tauri` 标签连起来：两个 workflow 各自的运行次数是 0，于是 2.0.x 每个 Release 都没有 `.hap`、`.deb`、`.rpm`，AppGallery 上传也从未发生，而且整个过程没有 任何报错——Silent miss。 在 `release-tauri.yml` 末尾加 `dispatch-platform-releases`：桌面/Android 矩阵结束后 用 `GITHUB_TOKEN`（`workflow_dispatch` 是文档里允许的两个例外之一，不需要 PAT，只要 `actions: write`）把同一个标签派发给这两个 workflow。之所以挂在标签构建尾部而不是给 它们加 `push:` 触发，是因为它们的 attach 步骤只等 10 分钟，而桌面矩阵要跑 40 分钟； 等到矩阵结束再派发，Release 一定已经存在。 - 鸿蒙：`channel` 取 `vars.HARMONY_AUTO_CHANNEL || 'none'`。默认走仓库分发路径（未签名 HAP 挂到 Release，不碰商店）；把仓库变量设为 `release` / `test` 即自动上传签名包作为 AGC 候选包（该上传不会提交审核，提交仍是人工决定）。 - Linux：`publish=true`，与鸿蒙一致自动挂到同一个 Release。因此 `docs/linux-egui-handoff/07-acceptance.md` 的真机验收从「打包后」前移为「打标签前」 的 gate，workflow 与 RELEASING.md 都已写明。 - 两个 workflow 仍然是 dispatch-only（契约测试要求），人工 dispatch 保留为修复路径。 - 补契约测试：`harmony-release-contract`、`linux-egui-release-contract` 断言尾部派发 存在、只用标签推送触发、默认不带签名渠道。
aeoform
force-pushed
the
ci/auto-dispatch-platform-releases
branch
from
October 26, 2026 14:08
9222580 to
1542739
Compare
第一次真正 dispatch `Release HarmonyOS` 就暴露了两个从未被发现的问题——这个 workflow 在有史以来的运行次数是 0，所以谁都没发现它其实跑不通： ``` error[E0463]: can't find crate for `core` = note: the `aarch64-unknown-linux-ohos` target may not be installed ``` `build-harmony-backend.sh` 用 `cargo build --target aarch64-unknown-linux-ohos`， `build-harmony-frontend.sh` 用 `npm run build`，而 hosted runner 既没有 Tier-2 OHOS target std 也没有 `node_modules`。`ci.yml` 的 `harmony-check` 两者都装了，release 这条 路径漏了，于是签名、证书校验、SDK 下载全部成功后卡在编译阶段。 按 `ci.yml` 的写法补齐：`cache-npm` + `npm ci`、`dtolnay/rust-toolchain@stable` 带 `targets: aarch64-unknown-linux-ohos`、`swatinem/rust-cache`（复用 `harmony-check` 的 `key: harmony-host`，标签构建只读不写）。 契约测试补断言：OHOS target 必须安装、必须 `npm ci`，且 target 列表要与 `ci.yml` 里 真正打 HAP 的那个 job 保持一致——只在一边加 target 是这次 bug 的形态。
上一个 run（40337344929）构建、签名、校验、挂 Release 全部成功，只有 AppGallery 上传失败： ``` /home/runner/work/_temp/...sh: line 2: --channel: command not found ##[error]Process completed with exit code 127 ``` 原因是那一步用的是 `run: >-` 折叠标量，且以注释开头。折叠后第一行变成 ``` # Only the signed package is uploaded; ... node scripts/upload-appgallery.mjs \ ``` 整行都是注释，命令连同续行反斜杠一起被吃掉，第二行 `--channel` 成了独立命令。 改成 `run: |` 字面块，注释移到 YAML 层（`#` 开头不会被折叠进脚本）。 契约测试加断言：`release-harmony.yml` 里任何 `run: >-` 之后都不允许紧跟注释行， 以及上传命令必须是可执行的 `node scripts/upload-appgallery.mjs \` 形式。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
摘要
Fixes #（无关联 issue：这是今天 v2.0.2-Beta.3 发版复盘出来的缺口）
今天的 Beta.3 有两个问题，都在同一个复盘里查出来，一起修：
1. 鸿蒙与 Linux 从来没被触发过。
Release HarmonyOS与Release Linux egui都是 dispatch-only，而没有任何东西把它们和v*-tauri标签连起来：Release HarmonyOS(390098596).hapRelease Linux egui(351490333).deb/.rpm2.0.x 每个 Release 都只有 dmg / exe / apk，鸿蒙既没出包也没进华为开发者联盟，Linux 从 2.0.0 拆成独立 workflow 之后也再没进过 Release，全程没有任何红灯——纯粹的 silent miss。
2. 即使手动 dispatch，鸿蒙这条也跑不通——两个独立的 bug，都是「0 次运行」掩盖下来的。先是 run 40335935436：：签名写入、证书/Profile 校验、SDK 下载全部成功，然后死在
build-harmony-backend.sh用cargo build --target aarch64-unknown-linux-ohos，build-harmony-frontend.sh用npm run build，而 hosted runner 既没有 Tier-2 OHOS target std 也没有node_modules。ci.yml的harmony-check两者都装了，release 这条路漏了。3. AGC 上传那一步本身也是坏的。 修完上面再跑（run 40337344929），构建、签名、校验、挂 Release 全绿，最后一步死在
它写成了
run: >-折叠标量又以注释开头，折叠后第一行整条都是注释（# ... node scripts/upload-appgallery.mjs \），命令连同续行反斜杠一起被吃掉，第二行--channel成了独立命令。也就是说：即使当初有人记得点 dispatch、即使 target 齐全，上传也永远不可能成功。修复 / 新增 / 改进
release-tauri.yml新增dispatch-platform-releases：needs: build，仅在push到v*-tauri标签时运行，用gh workflow run把同一个标签派发给release-harmony.yml（publish=true、upload_to_appgallery=true）和release-linux-egui.yml（publish=true）。GITHUB_TOKEN+permissions: actions: write派发：workflow_dispatch是 GitHub 文档里GITHUB_TOKEN触发事件的例外之一，不需要 PAT。push:触发：它们的 attach 步骤只等 Release 存在 10 分钟（seq 1 40× 15s），而桌面矩阵要跑 40–50 分钟，标签直触会在 attach 步超时失败。等矩阵结束再派发，Release 一定已在。HARMONY_CHANNEL = vars.HARMONY_AUTO_CHANNEL || 'none'。默认none= 未签名 HAP 挂 Release、不碰商店；设为release/test才自动上传签名包作为 AGC 候选包（upload-appgallery.mjs只替换候选包，不提交审核）。release-harmony.yml补齐 hosted runner 缺的两样：cache-npm+npm ci、dtolnay/rust-toolchain@stable带targets: aarch64-unknown-linux-ohos，以及swatinem/rust-cache（复用harmony-check的key: harmony-host，标签构建只读不写）。Upload to HUAWEI AppGallery Connect步骤：run: >-+ 注释 →run: |字面块，注释移到 YAML 层。docs/linux-egui-handoff/07-acceptance.md的 L01–L12 真机验收从「打包后」前移为「打标签前」的 gate，release-linux-egui.yml头部与RELEASING.md都已改写说明。harmony-release-contract：派发 job 必须存在、只在标签推送时触发、必须带tag/publish、默认必须走未签名渠道；OHOS target 必须安装、必须npm ci，且 target 列表必须与ci.yml里真正打 HAP 的 job 一致（只在一处加 target 正是这次 bug 的形态）；折叠标量不得以注释开头。harness新增：任何run: >-后面不允许紧跟注释行（这次 127 的形态），上传命令必须是可执行的node scripts/upload-appgallery.mjs \。linux-egui-release-contract：Linux 派发必须带同一个 tag 且publish=true。兼容
softprops/action-gh-release（契约要求全仓库唯一一个发布者）。v*-tauri标签后会多两次 workflow 运行（HAP ~15 分钟、Linux ~30 分钟），Release 仍然是 draft，由管理员发布（和现在一致）。channel=none，所以默认不会因为发个版就写进 AppGallery；要自动上架需显式设置仓库变量HARMONY_AUTO_CHANNEL=release。rust-cache（写harmony-check已有的 key），标签构建不写缓存。测试计划
node scripts/harmony-release-contract.test.mjs && node scripts/linux-egui-release-contract.test.mjs && node scripts/release-publication-contract.test.mjs && node scripts/workflow-concurrency-contract.test.mjs && node scripts/ci-cache-sharing.test.mjs && node scripts/ci-workflow-behavior.test.mjs && node scripts/repository-owner-contract.test.mjs && node scripts/windows-msi-release-contract.test.mjs && node scripts/linux-egui-tauri-free-contract.test.mjsbash -n语法检查、YAML 解析检查 job/needs/permissions/env）error[E0463] can't find crate for core：run 40335935436 → 本 PR 补 OHOS target +npm ci。--channel: command not found(127) run 40337344929 → 本 PR 修折叠标量。[appgallery] uploaded OpenLess_harmony_arm64-signed.app ... (release); submit it for review。v2.0.2-Beta.3-tauri现有OpenLess_harmony_arm64.hap/OpenLess_harmony.hap/SHA256SUMS，AGC 上有 release 候选包（提交审核仍人工）。beta版本补跑：run 40341511394test/build/publish全绿，Release 得到OpenLess-Linux-egui-2.0.2-Beta.3-141-x86_64.deb/.rpm+ 别名 +SHA256SUMS-linux。workflow_dispatch能选到修复分支，同名分支也推到了本仓库，合入后会删除。