Repository navigation
feat(ci): build the HarmonyOS hap in the release pipeline - #273
TiaraBasori wants to merge 2 commits into
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. |
Automated PR reviewHead: Review unavailable: Free OpenRouter review unavailable (HTTP 429); no paid fallback and no merge. Remaining gates
No PR code runs with the model key or write token. Free-only routing; provider/rate-limit failures never authorize a merge. Existing review findings must be resolved, not hidden by a new recommendation. |
iebb
left a comment
iebb
left a comment
There was a problem hiding this comment.
Reviewed current head 61685af, including interactions with #271/#272 and mithka-tdjson#4. Changes required before this becomes a release gate.
-
[P1] Do not publish a HAP without TDLib. release.yml:898-909 explicitly continues when the pinned manifest lacks tdjson-ohos-arm64.zip. The later ZIP check only requires pack.info and ets/modules.abc; it never requires or verifies libtdjson.so. The current submitted manifests therefore permit a supposedly verified release that cannot provide the app's native TDLib library. Require the pinned asset, verify its installed and packaged bytes, and prove the loader/exports boundary.
-
[P1] Do not treat every build failure as a signing-only failure. Lines 918-949 suppress any nonzero flutter build result and accept a shallow artifact-shape check. Use a supported unsigned build path or distinguish a specifically verified signing failure; compiler/resource/package failures must fail. Requiring this job for all releases before the complete dependency chain is ready can also block the existing release pipeline.
-
The overlay invocation is incompatible with #272: line 870 runs enable-ohos-plugins.sh without its mandatory apply argument, so the combined stack exits 2 before building.
The engine patch also changes behavior: it replaces requestAutoFill/requestAutoSave with failure callbacks, including on runtimes that pass the API-26 guard. That is not merely replacing compile-time type aliases. Pin a compatible engine/SDK or provide an explicitly reviewed capability fallback and relevant tests; do not claim unchanged runtime behavior without evidence.
Please complete the PR template and supply a credential-free, read-only Actions build of the exact assembled target with real pinned native artifacts and meaningful HAP checks. A publishing workflow is not a substitute for pre-merge validation; none was dispatched here. Keep this useful platform effort open for revision.
e53fb31 to
0b8a9cc
Compare
Address PR iebb#273 review findings: 1. Never publish a hap without TDLib. The pinned manifest now carries tdjson-ohos-arm64.zip (archive+member SHA-256/size plus a per-asset release_tag pointing at the immutable tdjson#4 secondary release), the installer treats it as required, and the install step re-hashes the installed ohos/entry/libs/arm64-v8a/libtdjson.so against that entry. The hap verification now requires libs/arm64-v8a/libtdjson.so inside the hap, compares its packaged bytes to the installed pinned bytes, checks the arm64 ELF identity, and asserts the td_json_client_* entry points the Dart loader resolves are present. pack.info/ets/modules.abc alone no longer pass the gate. 2. Only a specifically verified signing failure is tolerated. The build step captures the flutter log, and a nonzero exit only continues when the unsigned hap exists and the log names a signing cause; compiler, resource, dependency, or packaging failures fail the job. 3. scripts/enable-ohos-plugins.sh is invoked with its mandatory apply argument so the combined stack with iebb#272 no longer exits 2. 4. The engine embedding HAR patch is an explicitly reviewed capability fallback: it refuses to apply unless the engine still guards autofill below sdkApiVersion 26, so requestAutoFill/requestAutoSave stubs can never change behaviour on API 26+ runtimes without failing the build. Installer tests cover the required ohos asset, a manifest missing it, and the per-asset release tag override.
TiaraBasori
left a comment
TiaraBasori
left a comment
There was a problem hiding this comment.
在 0b8a9ccb 最新 rebase 上的增量（本 PR 新 head b6d192ae）：scripts/enable-ohos-plugins.sh apply 已补齐；pinned OHOS 资产安装改为必需（缺条目/摘要不匹配即失败）并对已装 ohos/entry/libs/arm64-v8a/libtdjson.so 复核 pinned member sha256/size；HAP 校验必含 libs/arm64-v8a/libtdjson.so 并与已安装字节按字节相等、校验 arm64 ELF 与 td_json_client_* 5 个 loader 入口；flutter build hap 仅容忍“已产出 unsigned hap + 日志命中签名失败”单一场景，否则 failing；引擎 HAR 的 autofill 类型补丁改为需 sdkApiVersion < 26 guard 在位才允许的受审核能力回退。
不可变 release：tdjson#4 的 228e9d3b 以 tdjson-ohos-<ver>-<sha>-mithka-<patch>-build-<build>-v<schema> 发布，永不删除既有 release/tag；producer/consumer 各自的 scripts/tdjson-manifest.json 的 tdjson-ohos-arm64.zip 条目通过 per-asset release_tag tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2 闭环，installer 按该标签下载校验。只读 assembled source 的 HAP 字节校验见本 PR 的 Verify and rename the hap。
Add a build-ohos job to the release workflow. It runs in the niuhuan harmony-next-flutter-pipeline container (HarmonyOS SDK API 22, hvigor/ohpm/node18), installs the 3.44.9+ohos-0.0.1-canary1 Flutter fork at /opt/flutter-ohos (cached), and patches the engine embedding HAR so its ArkTS compiles against API 22: autoFillManager API-26 types are replaced by local aliases, duplicate unfocus XComponent ids are made unique, and CompetitionStrategy.DEFAULT is spelled as its raw value. The patched har is repacked with the package/ member prefix ohpm requires. The job tolerates the not-yet-merged sibling ohos PRs: it runs scripts/enable-ohos-plugins.sh and installs the pinned tdjson-ohos-arm64.zip only when present (warning otherwise), and generates the ohos host via flutter create --platforms ohos when the repository has no ohos/ directory yet. flutter build hap exits non-zero without signing configs after hvigor produced the unsigned hap, so the build step warns and the verify step gates on the artifact: the hap must exist, unzip, and contain pack.info and ets/modules.abc. The release job now depends on build-ohos, requires exactly one mithka-*-ohos-arm64.hap asset, and cleans .hap assets when re-publishing.
Address PR iebb#273 review findings: 1. Never publish a hap without TDLib. The pinned manifest now carries tdjson-ohos-arm64.zip (archive+member SHA-256/size plus a per-asset release_tag pointing at the immutable tdjson#4 secondary release), the installer treats it as required, and the install step re-hashes the installed ohos/entry/libs/arm64-v8a/libtdjson.so against that entry. The hap verification now requires libs/arm64-v8a/libtdjson.so inside the hap, compares its packaged bytes to the installed pinned bytes, checks the arm64 ELF identity, and asserts the td_json_client_* entry points the Dart loader resolves are present. pack.info/ets/modules.abc alone no longer pass the gate. 2. Only a specifically verified signing failure is tolerated. The build step captures the flutter log, and a nonzero exit only continues when the unsigned hap exists and the log names a signing cause; compiler, resource, dependency, or packaging failures fail the job. 3. scripts/enable-ohos-plugins.sh is invoked with its mandatory apply argument so the combined stack with iebb#272 no longer exits 2. 4. The engine embedding HAR patch is an explicitly reviewed capability fallback: it refuses to apply unless the engine still guards autofill below sdkApiVersion 26, so requestAutoFill/requestAutoSave stubs can never change behaviour on API 26+ runtimes without failing the build. Installer tests cover the required ohos asset, a manifest missing it, and the per-asset release tag override.
b6d192a to
9f69b9f
Compare
Address PR iebb#273 review findings: 1. Never publish a hap without TDLib. The pinned manifest now carries tdjson-ohos-arm64.zip (archive+member SHA-256/size plus a per-asset release_tag pointing at the immutable tdjson#4 secondary release), the installer treats it as required, and the install step re-hashes the installed ohos/entry/libs/arm64-v8a/libtdjson.so against that entry. The hap verification now requires libs/arm64-v8a/libtdjson.so inside the hap, compares its packaged bytes to the installed pinned bytes, checks the arm64 ELF identity, and asserts the td_json_client_* entry points the Dart loader resolves are present. pack.info/ets/modules.abc alone no longer pass the gate. 2. Only a specifically verified signing failure is tolerated. The build step captures the flutter log, and a nonzero exit only continues when the unsigned hap exists and the log names a signing cause; compiler, resource, dependency, or packaging failures fail the job. 3. scripts/enable-ohos-plugins.sh is invoked with its mandatory apply argument so the combined stack with iebb#272 no longer exits 2. 4. The engine embedding HAR patch is an explicitly reviewed capability fallback: it refuses to apply unless the engine still guards autofill below sdkApiVersion 26, so requestAutoFill/requestAutoSave stubs can never change behaviour on API 26+ runtimes without failing the build. Installer tests cover the required ohos asset, a manifest missing it, and the per-asset release tag override.
9f69b9f to
64046a1
Compare
Address PR iebb#273 review findings: 1. Never publish a hap without TDLib. The pinned manifest now carries tdjson-ohos-arm64.zip (archive+member SHA-256/size plus a per-asset release_tag pointing at the immutable tdjson#4 secondary release), the installer treats it as required, and the install step re-hashes the installed ohos/entry/libs/arm64-v8a/libtdjson.so against that entry. The hap verification now requires libs/arm64-v8a/libtdjson.so inside the hap, compares its packaged bytes to the installed pinned bytes, checks the arm64 ELF identity, and asserts the td_json_client_* entry points the Dart loader resolves are present. pack.info/ets/modules.abc alone no longer pass the gate. 2. Only a specifically verified signing failure is tolerated. The build step captures the flutter log, and a nonzero exit only continues when the unsigned hap exists and the log names a signing cause; compiler, resource, dependency, or packaging failures fail the job. 3. scripts/enable-ohos-plugins.sh is invoked with its mandatory apply argument so the combined stack with iebb#272 no longer exits 2. 4. The engine embedding HAR patch is an explicitly reviewed capability fallback: it refuses to apply unless the engine still guards autofill below sdkApiVersion 26, so requestAutoFill/requestAutoSave stubs can never change behaviour on API 26+ runtimes without failing the build. Installer tests cover the required ohos asset, a manifest missing it, and the per-asset release tag override.
64046a1 to
9f208e7
Compare
iebb
left a comment
iebb
left a comment
There was a problem hiding this comment.
Reviewed exact head 9f208e70ddc1d0e48dadd5cafb3e003a0d62f4a9. Changes requested before publication.
Protected workflow changes and user-requested manual handling apply. In .github/workflows/release.yml:
- [P1] Credential boundary (
:41–43,654–707,901–911,964–978): the mutable third-partylatestcontainer runs as root, inherits contents-write, retains default checkout credentials and uses an unverified mutable toolchain reference while receiving application credentials. Pin verified immutable inputs; make validation/build read-only withpersist-credentials: false; isolate trusted publication credentials from untrusted toolchain execution. - [P1] Release availability (
:968–979,1089): the bare build/tee pipeline under errexit/pipefail exits beforePIPESTATUScapture on failure, defeating the intended signing-only classification. Container steps also require Bash features without an explicit Bash contract. Use safe status capture and explicit Bash; test success, specifically verified signing-only failure and compiler failure at the command boundary. Do not make the new job a mandatory dependency of all releases before the assembled path is validated. - [P2] Loader gate (
:1058–1068): byte-searching legacytd_json_client_*names does not verify callable exports for the app's actualtd_create_client_id,td_send,td_receive,td_executebindings. Verify defined dynamic exports and perform a real loader/startup check. - [P2] Autofill behavior (
:754–761,793–805): finding an SDK guard does not justify globally replacing supported-SDK autofill/save calls with failure callbacks. Preserve supported calls or provide a reviewed capability implementation; test both runtime SDK branches.
I withdraw the old missing-helper-apply, missing-TDLib-only-warns, superficial-two-member-HAP-only and every-build-failure-is-suppressed claims. The installed/packaged digest, size and byte-equality gates are real improvements, not fixes for the remaining issues above.
Complete the full mandatory contribution template with accurate command/platform evidence (prose classification plus a partial checklist is insufficient), and provide a credential-free, read-only build of the exact assembled target using real pinned native artifacts. These are source-derived security/release risks, not proof of a reproduced compromise. No release workflow was dispatched for this review.
No approval is granted. Current-base merged-result Quality is not yet fresh in the reviewed evidence; before publication require fresh ordinary PR Quality on this exact head merged with live master, applicable platform checks, resolved findings and genuine exact-head owner approval. No incoming PR code was executed for this review.
背景
适配纯血鸿蒙的最后一块：release 管线产出鸿蒙 hap。
Change
.github/workflows/release.yml新增build-ohosjob（containerghcr.io/niuhuan/harmony-next-flutter-pipeline-docker，HarmonyOS SDK API 22 + hvigor/ohpm/node18）：/opt/flutter-ohos。sdkApiVersion < 26提前返回，则补丁直接失败，requestAutoFill/requestAutoSave 的 stub 仅在 API 26 以下路径可达，上游修复后可移除。bash scripts/enable-ohos-plugins.sh apply（此前漏带参数导致整栈在与 feat(deps): federated HarmonyOS plugin implementations #272 合并后直接退出 2）。tdjson-ohos-arm64.zip安装改为必需：缺条目或 SHA/size 不一致直接失败，安装后对已装ohos/entry/libs/arm64-v8a/libtdjson.so复核 pinned member 摘要。flutter build hap仅容忍“已产出entry-default-unsigned.hap且日志命中签名失败”的单一失败（signing|signature|keystore|p12|cer|profile），其他 nonzero（编译/资源/依赖）一律失败。pack.info、ets/modules.abc与libs/arm64-v8a/libtdjson.so均存在，已打包字节与 pinned 条目size/sha256一致，已打包字节与已安装字节按字节相等，ELF 头为 arm64，且暴露td_json_client_{create,send,receive,execute,destroy}5 个导出供td_client加载。releasejob：needs已加build-ohos；硬校验恰好一个mithka-*-ohos-arm64.hap。scripts/install-tdjson-artifact.py：tdjson-ohos-arm64.zip改为 REQUIRED，校验支持按资产的release_tag覆盖（与 tdjson#4 次级固定标签闭环）。scripts/tdjson-manifest.json：新增该 OHOS 条目（per-assetrelease_tag指向tdjson-ohos-1.8.68-c15d3f5a5de6-mithka-2e7f8ff14657-build-f6b13ce5aa13-v2）。test/tdjson_artifact_installer_test.dart：覆盖 required ohos、缺条目拒绝、per-asset release_tag 覆盖。Telegram API Terms classification
Compliant / unchanged — 管线与宿主构建相关，无 Telegram API 语义变更。
Basic checks
python3 - <<'PY' \nimport yaml; yaml.safe_load(open(f))\nPY对build-ohos.yml/release.yml校验通过。flutter analyze --no-pub/flutter test --no-pub test/tdjson_artifact_installer_test.dart：tdjson_artifact_installer_test.dart10/10 全过，analyze 仅存量警告。libs/arm64-v8a/libtdjson.so已校验证据见本 PR 的Verify and rename the hap（含 loader/exports 边界与 installed↔packaged 字节一致性）。Section 1.4 exception checks
不适用：本 PR 未改变消息能力与 1.4 例外判定。
验证（本次增量在 0b8a9cc 最新 rebase 上的修订）
0b8a9ccb基础上的增量：enable-ohos-plugins.sh apply、必需的 pinned OHOS 资产安装与 HAP 内libs/arm64-v8a/libtdjson.so的已安装/已打包字节一致性（含 arm64 ELF 与 5 个 td_json_client_* 入口的 loader 边界证据）、非签名类失败一律抛出、受控的 API 22 能力回退门控。build-ohos.yml以完整构建标识tdjson-ohos-<version>-<sha12>-mithka-<patch>-build-<build>-v<schema>发布，永不删除既有 release/tag，重建用-rebuild-<run-id>-<attempt>新标签；权限contents: read全局，publishjob 限write，persist-credentials: false+ digest-pinned SDK 容器。#271与#273各自的scripts/tdjson-manifest.json的新增tdjson-ohos-arm64.zip条目都指向228e9d3b所定义的 tdjson 次级 release 的一级资源，scripts/install-tdjson-artifact.py按 per-assetrelease_tag下载并校验。关联
feat/ohos-host / feat/ohos-platform / feat/ohos-pubspec / mithka-tdjson feat/ohos-tdjson（228e9d3b）。