DeepChat Linux ARM64 支持从 CI 任务清单到可复用打包工作流的全链路解析【免费下载链接】deepchatDeepChat - A smart assistant that connects powerful AI to your personal world项目地址: https://gitcode.com/GitHub_Trending/dee/deepchat本文以 DeepChat 的 Linux ARM64 支持任务清单docs/features/linux-arm64-support/tasks.md为主线完整还原该特性的七项任务T01–T07、每项任务在 CI 工作流中的落点以及配套的验证证据与完成定义Done Definition。读完后你将掌握如何在 Electron 桌面项目中为 ARM64 Linux 新增原生打包链路、如何用workflow_call可复用工作流统一 Build/Release/回归三条调用方以及为什么 CUA 插件在linux/arm64上必须被按契约排除而不是简单删掉。背景为什么需要一份专门的 ARM64 任务清单在实现之前DeepChat 仓库里其实已经存在大部分 Linux ARM64 打包原语——Electron Builder 配置、ARM64 原生依赖映射、按架构区分 runtime 的installRuntime脚本见 package.json 中的installRuntime:linux:arm64、build:linux:arm64等脚本定义。但当时的问题在于Build 与 Release 工作流只为 Linux x64 排程硬编码 x64 的 unpacked 输出路径打包流程无条件捆绑 CUAComputer Use插件。而 CUA 在 Linux ARM64 上是有意不支持的其锁定的上游 driver 发布版本没有匹配的 ARM64 runtime 资产。因此该特性的目标很明确——在 Build 与 Release CI 中产出 Linux ARM64 应用产物同时让 CUA 在该目标上保持隐藏、不捆绑、不验证。这个契约在 plugins/cua/plugin.json 中有直接证据engines.targets列表为darwin/arm64、darwin/x64、win32/x64、win32/arm64、linux/x64不含linux/arm64即插件可见性门控天然排斥 ARM64 Linux。任务清单T01–T07完整解析任务清单本身是该文档的核心骨架。T01–T06 已完成勾选T07 尚待维护者授权的远端运行逐项说明如下任务状态内容要点T01完成在 Build CI 中新增 Linux ARM64 矩阵项新增原生 ARM64 runner安装目标架构 runtime 并参数化 unpacked 路径在 ARM64 上跳过 CUA 捆绑与验证T02完成在 Release CI 中新增 Linux ARM64镜像 Build 的矩阵与 CUA 跳过逻辑上传架构专属构建产物收集 ARM64 包并更新 Release 元数据T03完成新增回归覆盖校验两条工作流的矩阵与输出目录、工作流级 CUA 跳过、保留业务可见性与直接打包拒绝的测试覆盖T04完成本地验证跑聚焦测试 格式化、i18n、lint 检查T05完成提交并推送特性分支手动触发 Linux Build CI 确认 ARM64 job 打包成功向dev开 Draft PRT06完成将 Linux 打包所有权收敛到单一可复用工作流_package-linux.ymlBuild、Release、回归三方复用生成精确的架构专属包清单与独立的 Linux 更新元数据用契约测试覆盖调用方、CUA 排除、产物命名与发布组装T07未完成远端验证可复用工作流仅在维护者授权后推送让两个 Linux 目标都跑完 distribution 与 verification 两种模式确认latest-linux-arm64.yml只引用 ARM64 AppImageT01/T02Build 与 Release 的 ARM64 矩阵两个调用方工作流现在的写法高度对称矩阵定义在 build.yml 与 release.yml 中# .github/workflows/build.ymlrelease.yml 的 package-linux job 同理 package-linux: name: build-linux(${{ matrix.arch }}) if: inputs.platform all || inputs.platform linux strategy: fail-fast: false matrix: arch: [x64, arm64] uses: ./.github/workflows/_package-linux.yml with: source-sha: ${{ github.sha }} arch: ${{ matrix.arch }} artifact-purpose: distribution enforce-installer-size: falseRelease 侧release.yml 第 129–148 行额外要求enforce-installer-size: true并把source-sha换成 preflight job 解析出的不可变提交needs.preflight.outputs.sha——这保证了发布产物可以回溯到一个精确的 40 位 SHA。目标矩阵摘自同目录 spec.mdTargetRunner应用包CUAFeishulinux/x64ubuntu-24.04必需捆绑并验证捆绑并验证linux/arm64ubuntu-24.04-arm必需跳过捆绑并验证T03契约测试如何锁住行为T03 的回归覆盖对应仓库中的测试文件test/main/scripts/packageWorkflow.test.ts 断言了 runner 选择表达式inputs.arch arm64 ubuntu-24.04-arm || ubuntu-24.04、三条调用方的arch: [x64, arm64]矩阵以及deepchat-package-linux-arm64等六个架构专属产物名test/main/build/electronBuilderConfig.test.ts 校验 unpacked 输出目录映射test/main/plugin/pluginService.test.ts 则覆盖 CUA 的supportedTargets白名单[darwin/arm64, darwin/x64, win32/x64, win32/arm64, linux/x64]与在linux/arm64运行时上的业务不可见性。T04本地验证命令计划文档 plan.md 明确了本地验证顺序——先跑聚焦的工作流/插件打包测试再执行仓库级检查pnpm run format pnpm run i18n pnpm run lintT05/T07远端证据的边界T05 的证据已经记录Linux ARM64 打包、原生依赖检查、插件验证与产物上传在 Build Application run 29933595490 中通过ARM64 job 中 CUA 捆绑与验证按预期被跳过且已开 Draft PR #2006。T07 之所以仍是未勾选项是因为可复用工作流迁移T06的远端验证依赖维护者授权必须等授权推送后两个 Linux 目标在 distribution 与 verification 两种artifact-purpose模式下都成功并且确认latest-linux-arm64.yml只引用 ARM64 AppImage迁移才算远端验证完成。这一本地已验证、远端待验证的状态在 spec.md 的 Status 一节中被明确标注。T06 深度解析_package-linux.yml可复用工作流T06 是整个特性的架构核心把原来散落在 Build/Release 中的 Linux 打包逻辑收敛到一个workflow_call可复用工作流.github/workflows/_package-linux.yml调用方只需声明式传参。输入契约on: workflow_call: inputs: source-sha: # 40 位不可变源提交必需 required: true arch: # x64 或 arm64必需 required: true artifact-purpose: # distribution 或 verification必需 required: true enforce-installer-size: # 是否对照已提交的包体积基线必需布尔 required: true其中artifact-purpose决定了产物上传策略distribution调用方上传完整契约产物deepchat-package-linux-${{ arch }}verification调用方只上传诊断信息deepchat-package-diagnostics-linux-${{ arch }}保留 7 天。package-regression.yml 正是以verificationenforce-installer-size: true复用同一工作流做定时回归cron37 18 * * *。架构相关的行为差异全部内聚在此架构专属逻辑只有三处且都收敛在工作流内部调用方完全无感runs-on: ${{ inputs.arch arm64 ubuntu-24.04-arm || ubuntu-24.04 }} # job 级环境变量 UNPACKED_DIRECTORY: ${{ inputs.arch arm64 linux-arm64-unpacked || linux-unpacked }}关键步骤链均按inputs.arch参数化安装目标 runtimepnpm run installRuntime:linux:${{ inputs.arch }}对应 scripts/install-runtime.mjs其后还有installRuntime:duckdb:vss -- --platform linux --arch arch与 DuckDB VSS smoke 检查构建pnpm run build注入 GitHub OAuth 相关 secret 环境变量CUA 捆绑与验证——仅 x64- name: Bundle CUA plugin if: inputs.arch x64 run: pnpm run plugin:bundle -- --name cua --platform linux --arch ${{ inputs.arch }}验证步骤Verify bundled CUA plugin同样带if: inputs.arch x64。这就是 T01ARM64 上跳过 CUA的工作流级实现Feishu 双架构共用pnpm run plugin:bundle -- --name feishu ...无条件执行随后统一plugin:verify打包pnpm exec electron-builder --linux --${{ inputs.arch }} --publishnever包后验证在dist/${UNPACKED_DIRECTORY}下验证 DuckDB VSS 扩展、OpenDAL 原生包并用unshare --net网络隔离跑 Light OCR 离线 smoke清单与上传scripts/ci/package-manifest.mjs生成目标专属清单distribution 模式上传deepchat-package-linux-archverification 模式仅上传诊断。值得注意的是package.json 中的本地脚本build:linux:arm64与 CI 保持一致的语义只捆绑 feishu、不捆绑 cua即跳过 CUA这一契约在本地构建与 CI 两条路径上都被遵守。Release 组装latest-linux-arm64.yml独立成文在 release.yml 的assemblejob 中deepchat-package-linux-arm64作为六个架构专属产物之一被digest-mismatch: error地下载随后scripts/ci/assemble-release.mjs在 fail-closed 模式下组装分别发布各架构的 AppImage 与 tarball并独立生成latest-linux-arm64.yml与latest-linux-x64.yml。从源码结构看两个 Linux 架构的 updater 元数据从不合并——这正是 spec 验收标准Release CI 独立保留latest-linux-arm64.yml的落地方式也是 T07 远端确认的检查点之一。CUA 契约三层防线CUA 在linux/arm64上不可用由三层共同保证且不需要新增业务逻辑分支清单可见性门控plugins/cua/plugin.json 的engines.targets不含linux/arm64业务层插件呈现逻辑据此隐藏该插件直接打包拒绝打包校验对linux/arm64的 CUA 请求返回 unsupported-target 错误对应 spec 验收标准Direct CUA packaging forlinux/arm64continues to fail with an unsupported-target errorCI 工作流级跳过if: inputs.arch x64确保 ARM64 job 根本不执行 CUA 捆绑/验证配合 T03 的契约测试使 CI 无法意外把 CUA 打进 ARM64 包。完成定义与验证证据Done Definition原文保留于 tasks.mdBuild 与 Release 工作流都定义了可用的 Linux x64 与 ARM64 jobLinux ARM64 应用产物按契约且按 CI 执行排除 CUABuild、Release、package regression 共享同一份 Linux 打包实现原始 Build CI 与 Draft PR 证据仍然有效可复用工作流迁移等待维护者授权的远端运行。Validation Evidence 同样记录在案打包、原生依赖检查、插件验证与产物上传在 Build Application run 29933595490 通过ARM64 job 中 CUA 捆绑与验证按预期跳过Draft PR #2006 已提交。小结这份任务清单展示了一个多架构 Electron 桌面项目新增 CPU 架构支持的完整工程范式先在调用方铺矩阵T01/T02再用契约测试钉死行为T03本地全量检查T04远端跑通一次拿证据T05最后把重复实现收敛为单一workflow_call工作流并区分 distribution/verification 两种用途T06把无法本地闭环的远端验证显式留成未勾选项T07。对 DeepChat 而言ARM64 的支持同时包含了精确声明哪些能力不支持——CUA 的三层排除契约保证了这一边界不会被后续改动悄悄破坏。【免费下载链接】deepchatDeepChat - A smart assistant that connects powerful AI to your personal world项目地址: https://gitcode.com/GitHub_Trending/dee/deepchat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/17 9:22:54 · 阅读 1.2k DeepChat Linux ARM64 支持：从 CI 任务清单到可复用打包工作流的全链路解析
DeepChat Linux ARM64 支持从 CI 任务清单到可复用打包工作流的全链路解析【免费下载链接】deepchatDeepChat - A smart assistant that connects powerful AI to your personal world项目地址: https://gitcode.com/GitHub_Trending/dee/deepchat本文以 DeepChat 的 Linux ARM64 支持任务清单docs/features/linux-arm64-support/tasks.md为主线完整还原该特性的七项任务T01–T07、每项任务在 CI 工作流中的落点以及配套的验证证据与完成定义Done Definition。读完后你将掌握如何在 Electron 桌面项目中为 ARM64 Linux 新增原生打包链路、如何用workflow_call可复用工作流统一 Build/Release/回归三条调用方以及为什么 CUA 插件在linux/arm64上必须被按契约排除而不是简单删掉。背景为什么需要一份专门的 ARM64 任务清单在实现之前DeepChat 仓库里其实已经存在大部分 Linux ARM64 打包原语——Electron Builder 配置、ARM64 原生依赖映射、按架构区分 runtime 的installRuntime脚本见 package.json 中的installRuntime:linux:arm64、build:linux:arm64等脚本定义。但当时的问题在于Build 与 Release 工作流只为 Linux x64 排程硬编码 x64 的 unpacked 输出路径打包流程无条件捆绑 CUAComputer Use插件。而 CUA 在 Linux ARM64 上是有意不支持的其锁定的上游 driver 发布版本没有匹配的 ARM64 runtime 资产。因此该特性的目标很明确——在 Build 与 Release CI 中产出 Linux ARM64 应用产物同时让 CUA 在该目标上保持隐藏、不捆绑、不验证。这个契约在 plugins/cua/plugin.json 中有直接证据engines.targets列表为darwin/arm64、darwin/x64、win32/x64、win32/arm64、linux/x64不含linux/arm64即插件可见性门控天然排斥 ARM64 Linux。任务清单T01–T07完整解析任务清单本身是该文档的核心骨架。T01–T06 已完成勾选T07 尚待维护者授权的远端运行逐项说明如下任务状态内容要点T01完成在 Build CI 中新增 Linux ARM64 矩阵项新增原生 ARM64 runner安装目标架构 runtime 并参数化 unpacked 路径在 ARM64 上跳过 CUA 捆绑与验证T02完成在 Release CI 中新增 Linux ARM64镜像 Build 的矩阵与 CUA 跳过逻辑上传架构专属构建产物收集 ARM64 包并更新 Release 元数据T03完成新增回归覆盖校验两条工作流的矩阵与输出目录、工作流级 CUA 跳过、保留业务可见性与直接打包拒绝的测试覆盖T04完成本地验证跑聚焦测试 格式化、i18n、lint 检查T05完成提交并推送特性分支手动触发 Linux Build CI 确认 ARM64 job 打包成功向dev开 Draft PRT06完成将 Linux 打包所有权收敛到单一可复用工作流_package-linux.ymlBuild、Release、回归三方复用生成精确的架构专属包清单与独立的 Linux 更新元数据用契约测试覆盖调用方、CUA 排除、产物命名与发布组装T07未完成远端验证可复用工作流仅在维护者授权后推送让两个 Linux 目标都跑完 distribution 与 verification 两种模式确认latest-linux-arm64.yml只引用 ARM64 AppImageT01/T02Build 与 Release 的 ARM64 矩阵两个调用方工作流现在的写法高度对称矩阵定义在 build.yml 与 release.yml 中# .github/workflows/build.ymlrelease.yml 的 package-linux job 同理 package-linux: name: build-linux(${{ matrix.arch }}) if: inputs.platform all || inputs.platform linux strategy: fail-fast: false matrix: arch: [x64, arm64] uses: ./.github/workflows/_package-linux.yml with: source-sha: ${{ github.sha }} arch: ${{ matrix.arch }} artifact-purpose: distribution enforce-installer-size: falseRelease 侧release.yml 第 129–148 行额外要求enforce-installer-size: true并把source-sha换成 preflight job 解析出的不可变提交needs.preflight.outputs.sha——这保证了发布产物可以回溯到一个精确的 40 位 SHA。目标矩阵摘自同目录 spec.mdTargetRunner应用包CUAFeishulinux/x64ubuntu-24.04必需捆绑并验证捆绑并验证linux/arm64ubuntu-24.04-arm必需跳过捆绑并验证T03契约测试如何锁住行为T03 的回归覆盖对应仓库中的测试文件test/main/scripts/packageWorkflow.test.ts 断言了 runner 选择表达式inputs.arch arm64 ubuntu-24.04-arm || ubuntu-24.04、三条调用方的arch: [x64, arm64]矩阵以及deepchat-package-linux-arm64等六个架构专属产物名test/main/build/electronBuilderConfig.test.ts 校验 unpacked 输出目录映射test/main/plugin/pluginService.test.ts 则覆盖 CUA 的supportedTargets白名单[darwin/arm64, darwin/x64, win32/x64, win32/arm64, linux/x64]与在linux/arm64运行时上的业务不可见性。T04本地验证命令计划文档 plan.md 明确了本地验证顺序——先跑聚焦的工作流/插件打包测试再执行仓库级检查pnpm run format pnpm run i18n pnpm run lintT05/T07远端证据的边界T05 的证据已经记录Linux ARM64 打包、原生依赖检查、插件验证与产物上传在 Build Application run 29933595490 中通过ARM64 job 中 CUA 捆绑与验证按预期被跳过且已开 Draft PR #2006。T07 之所以仍是未勾选项是因为可复用工作流迁移T06的远端验证依赖维护者授权必须等授权推送后两个 Linux 目标在 distribution 与 verification 两种artifact-purpose模式下都成功并且确认latest-linux-arm64.yml只引用 ARM64 AppImage迁移才算远端验证完成。这一本地已验证、远端待验证的状态在 spec.md 的 Status 一节中被明确标注。T06 深度解析_package-linux.yml可复用工作流T06 是整个特性的架构核心把原来散落在 Build/Release 中的 Linux 打包逻辑收敛到一个workflow_call可复用工作流.github/workflows/_package-linux.yml调用方只需声明式传参。输入契约on: workflow_call: inputs: source-sha: # 40 位不可变源提交必需 required: true arch: # x64 或 arm64必需 required: true artifact-purpose: # distribution 或 verification必需 required: true enforce-installer-size: # 是否对照已提交的包体积基线必需布尔 required: true其中artifact-purpose决定了产物上传策略distribution调用方上传完整契约产物deepchat-package-linux-${{ arch }}verification调用方只上传诊断信息deepchat-package-diagnostics-linux-${{ arch }}保留 7 天。package-regression.yml 正是以verificationenforce-installer-size: true复用同一工作流做定时回归cron37 18 * * *。架构相关的行为差异全部内聚在此架构专属逻辑只有三处且都收敛在工作流内部调用方完全无感runs-on: ${{ inputs.arch arm64 ubuntu-24.04-arm || ubuntu-24.04 }} # job 级环境变量 UNPACKED_DIRECTORY: ${{ inputs.arch arm64 linux-arm64-unpacked || linux-unpacked }}关键步骤链均按inputs.arch参数化安装目标 runtimepnpm run installRuntime:linux:${{ inputs.arch }}对应 scripts/install-runtime.mjs其后还有installRuntime:duckdb:vss -- --platform linux --arch arch与 DuckDB VSS smoke 检查构建pnpm run build注入 GitHub OAuth 相关 secret 环境变量CUA 捆绑与验证——仅 x64- name: Bundle CUA plugin if: inputs.arch x64 run: pnpm run plugin:bundle -- --name cua --platform linux --arch ${{ inputs.arch }}验证步骤Verify bundled CUA plugin同样带if: inputs.arch x64。这就是 T01ARM64 上跳过 CUA的工作流级实现Feishu 双架构共用pnpm run plugin:bundle -- --name feishu ...无条件执行随后统一plugin:verify打包pnpm exec electron-builder --linux --${{ inputs.arch }} --publishnever包后验证在dist/${UNPACKED_DIRECTORY}下验证 DuckDB VSS 扩展、OpenDAL 原生包并用unshare --net网络隔离跑 Light OCR 离线 smoke清单与上传scripts/ci/package-manifest.mjs生成目标专属清单distribution 模式上传deepchat-package-linux-archverification 模式仅上传诊断。值得注意的是package.json 中的本地脚本build:linux:arm64与 CI 保持一致的语义只捆绑 feishu、不捆绑 cua即跳过 CUA这一契约在本地构建与 CI 两条路径上都被遵守。Release 组装latest-linux-arm64.yml独立成文在 release.yml 的assemblejob 中deepchat-package-linux-arm64作为六个架构专属产物之一被digest-mismatch: error地下载随后scripts/ci/assemble-release.mjs在 fail-closed 模式下组装分别发布各架构的 AppImage 与 tarball并独立生成latest-linux-arm64.yml与latest-linux-x64.yml。从源码结构看两个 Linux 架构的 updater 元数据从不合并——这正是 spec 验收标准Release CI 独立保留latest-linux-arm64.yml的落地方式也是 T07 远端确认的检查点之一。CUA 契约三层防线CUA 在linux/arm64上不可用由三层共同保证且不需要新增业务逻辑分支清单可见性门控plugins/cua/plugin.json 的engines.targets不含linux/arm64业务层插件呈现逻辑据此隐藏该插件直接打包拒绝打包校验对linux/arm64的 CUA 请求返回 unsupported-target 错误对应 spec 验收标准Direct CUA packaging forlinux/arm64continues to fail with an unsupported-target errorCI 工作流级跳过if: inputs.arch x64确保 ARM64 job 根本不执行 CUA 捆绑/验证配合 T03 的契约测试使 CI 无法意外把 CUA 打进 ARM64 包。完成定义与验证证据Done Definition原文保留于 tasks.mdBuild 与 Release 工作流都定义了可用的 Linux x64 与 ARM64 jobLinux ARM64 应用产物按契约且按 CI 执行排除 CUABuild、Release、package regression 共享同一份 Linux 打包实现原始 Build CI 与 Draft PR 证据仍然有效可复用工作流迁移等待维护者授权的远端运行。Validation Evidence 同样记录在案打包、原生依赖检查、插件验证与产物上传在 Build Application run 29933595490 通过ARM64 job 中 CUA 捆绑与验证按预期跳过Draft PR #2006 已提交。小结这份任务清单展示了一个多架构 Electron 桌面项目新增 CPU 架构支持的完整工程范式先在调用方铺矩阵T01/T02再用契约测试钉死行为T03本地全量检查T04远端跑通一次拿证据T05最后把重复实现收敛为单一workflow_call工作流并区分 distribution/verification 两种用途T06把无法本地闭环的远端验证显式留成未勾选项T07。对 DeepChat 而言ARM64 的支持同时包含了精确声明哪些能力不支持——CUA 的三层排除契约保证了这一边界不会被后续改动悄悄破坏。【免费下载链接】deepchatDeepChat - A smart assistant that connects powerful AI to your personal world项目地址: https://gitcode.com/GitHub_Trending/dee/deepchat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考