desktop-cc-gui构建发布完全指南：pnpm workspace、macOS签名与GitHub Actions CI详解

desktop-cc-gui构建发布完全指南pnpm workspace、macOS签名与GitHub Actions CI详解【免费下载链接】desktop-cc-guiMulti-engine AI coding desktop client (Tauri). Claude Code, Codex, Gemini, OpenCode, DeepSeek Harness and more in one GUI.项目地址: https://gitcode.com/zhukunpenglinyutong/desktop-cc-guidesktop-cc-guiCC GUI是一个基于 Tauri 2 React Rust 的开源多引擎 AI 编程桌面客户端把 Claude Code、Codex 等命令行 AI 引擎装进统一的图形界面。本文带你完整看懂它的构建发布体系pnpm workspace 工作区如何管理依赖、macOS 签名与公证如何跑通、GitHub Actions 一条流水线如何产出三平台安装包并发布自动更新。为什么一个桌面 AI 编程客户端需要完整的发布体系 ️CC GUI 用 Tauri 2 开发Rust 后端 前端 UI要同时交付 macOS、Windows、Linux 三端还要过系统安全关卡、支持应用内自动更新。这套体系涉及三件事依赖管理前端用 pnpm workspace内置一个插件 SDK 子包签名与公证macOS 必须 Developer ID 签名 公证Windows/Linux 依赖 Tauri 的 minisign 签名文件CI 流水线手动触发的 GitHub Actions 工作流完成校验、三平台构建、聚合发布和版本号自动递增。下面逐一拆解。一、pnpm workspace 工作区结构两个包如何协作1.1 根包应用本身根目录 package.json 定义了主包ccgui-next有两个值得注意的设计锁定包管理器packageManager: pnpm10.29.3保证所有人和 CI 用同一个 pnpm 版本避免依赖漂移工作区依赖ccgui/plugin-sdk: workspace:*见 package.json表示直接从本仓库的工作区包引用插件 SDK而不是去 npm 拉取——本地改 SDK应用立即生效。1.2 工作区声明与供应链加固pnpm-workspace.yaml 声明工作区成员为packages/*目前只包含自研插件 SDKpackages/plugin-sdk/插件开发可参考 docs/plugin-development-guide.zh-CN.md。更亮眼的是文件里的供应链加固配置配置作用minimumReleaseAge: 10080延迟安装发布不足 7 天的新包版本让恶意发布有时间被下架patchedDependencies给framer-motion12.43.0打补丁patches/framer-motion12.43.0.patch修复拖拽回滚卡顿问题trustPolicy: no-downgrade拒绝信任信号签名/溯源变差的依赖解析结果对新手来说记住一点pnpm install会同时安装根包和子包依赖共享一个 pnpm-lock.yaml 锁文件这是发布可复现的基础。1.3 常用脚本速查根 package.json 中的核心脚本命令干什么pnpm dev以开发模式启动 Tauri 应用Vite HMRpnpm build类型检查tsc Vite 前端打包pnpm test运行 Vitest 单元测试pnpm build:mac调用本地 macOS 签名构建脚本./scripts/build-signed-macos.shpnpm build:mac:skip-notarize同上但跳过公证适合本地快速出包二、Tauri 配置版本号与签名信息都在这一个文件发布流程的核心配置集中在 src-tauri/tauri.conf.json应用身份productName: CC GUI、version: 1.0.3、identifier: com.zhukunpenglinyutong.ccgui——三者分别决定应用名、升级判断和 Windows NSIS 升级替换逻辑打包策略tauri.conf.jsontargets: all全平台打包createUpdaterArtifacts: true表示每次构建都额外产出自动更新用的签名压缩包macOS 签名身份signingIdentity: Developer ID Application: kunpeng zhu (RLHBM56QRH)构建机证书库里必须存在这条身份才能签名更新器插件tauri.conf.json内置 minisign 公钥和latest.json地址客户端后台轮询该文件判断新版本。Windows 端另有 src-tauri/tauri.windows.conf.json通过 CI 的--config参数合并进主配置用于内嵌 WebView2 引导程序保证老系统上首次运行能自动装 WebView2。 版本号是三处同步的package.json、tauri.conf.json、src-tauri/Cargo.toml。发布前手动 bump发布后 CI 会自动递增见第四节。三、macOS 签名与公证安装包如何过 GatekeepermacOS 分发第三方应用必须完成三步签名codesign→ 公证notarize→ 装订staple。CC GUI 的 CI 在 macOS 构建任务里完整实现了这条链对应 release.yml 的几个步骤导入签名证书从仓库 Secrets 取出 base64 的.p12证书APPLE_CERTIFICATE_P12解码后导入临时钥匙串build.keychain并用security set-key-partition-list放行 codesign 访问配置公证凭据用 Apple API KeyKey ID / Issuer /.p8私钥执行xcrun notarytool store-credentials保存公证 profile构建应用release.yml执行pnpm exec tauri build --bundles app,dmg。因为无头headlessCI 机器上 DMG 打包偶发失败工作流做了最多 3 次重试失败才判错——配合 Rust 缓存第二次重试只需增量编译公证并装订release.ymlxcrun notarytool submit --wait等待 Apple 校验通过再xcrun stapler staple把公证票据打进 DMG离线环境也能验证。本地开发时只需在 Mac 上执行pnpm build:mac它会走仓库内置的build-signed-macos.sh脚本完成同样的签名流程没有公证环境可用pnpm build:mac:skip-notarize快速出包自测。四、GitHub Actions 发布流水线逐步拆解整条流水线定义在 .github/workflows/release.yml采用手动触发workflow_dispatch需要填入版本号作为门禁。整体是 5 个 job 的流水线4.1 preflight发版前置校验防呆第一关release.yml 里的 preflight 任务做三件事任一不过就快速失败版本号必须符合X.Y.Z格式输入版本必须与src-tauri/tauri.conf.json中的version完全一致远端不能已存在v{版本}tag——防止同一个版本发布两次。这一步避免了点了运行就把 main 分支当前内容按错误版本发布出去的经典事故。4.2 macOS双架构矩阵构建release.yml 用 matrix 策略并行构建两个版本Runner架构产物macos-latestApple Siliconaarch64签名 DMG 更新包macos-15-intelx86_64签名 DMG 更新包环境准备很规范pnpm/action-setup Node 20启用 pnpm 缓存 Rust stable swatinem/rust-cache按平台-架构划分缓存键。依赖安装统一用pnpm install --frozen-lockfile --ignore-scripts保证与锁文件一致且不执行可疑的安装脚本。每个架构的产物包含三类文件ccgui_{版本}_{架构}.dmg分发给用户的安装包ccgui_{架构}.app.tar.gz自动更新器下载的压缩应用包ccgui_{架构}.app.tar.gz.sigminisign 签名更新器校验用。4.3 LinuxAppImage 构建与 Wayland 库裁剪Linux 任务release.yml在ubuntu-24.04上先安装 webkit2gtk、GTK3 等 Tauri 依赖构建--bundles appimage。有一个细节特别值得学习打包进 AppImage 的 Wayland 客户端库会与宿主机系统库冲突导致崩溃。流水线用 scripts/prune-appimage-wayland-libs.mjs 把 AppImage 解包、删除usr/lib下所有libwayland-*、再重打包。因为裁剪后原签名失效CI 还会用 Tauri signer 对裁剪后的镜像重新签名release.yml。4.4 WindowsNSIS 安装包Windows 任务release.yml执行pnpm exec tauri build --config src-tauri/tauri.windows.conf.json --bundles nsis产出带 WebView2 引导程序的.exe安装包及.sig签名文件。4.5 release聚合产物并发布release job 等三个平台全部成功后运行依次完成下载全部产物macOS 双架构、AppImage、NSIS到release-artifacts/生成latest.json按 Tauri v2 更新器清单格式为每个平台填入下载 URL 和签名自动生成发布说明从上一个 tag 到当前提交的 conventional commits 中把feat/fix/perf前缀的提交归类为 New Features / Fixes / Performance Improvements创建 Releasegh release create v{版本}上传全部资产自动 bump 版本号并开 PR按十进制进位规则递增1.0.9 → 1.1.01.9.9 → 2.0.0同时改package.json、tauri.conf.json、Cargo.toml三处推分支并gh pr create提交人工合并release.yml。一个真实踩过的坑写在了工作流注释里GitHub 会把资产名中的空格替换为点CC GUI_1.0.1_x64-setup.exe变成CC.GUI_...latest.json必须指向改名后的 URL否则更新器下载 404——生成逻辑中专门做了asset_name()替换release.yml。五、自动更新通道latest.json 背后的机制 把前面内容串起来createUpdaterArtifacts: true让每次构建产出带.sig的更新包 → 发布任务把所有平台的 URL 签名写进latest.json并上传 → 已安装客户端按 tauri.conf.json 中配置的 endpoint 轮询latest.json→ 发现新版本后下载、校验 minisign 签名、静默替换。这也解释了为什么签名私钥TAURI_SIGNING_PRIVATE_KEY是整条流水线的关键 SecretmacOS、Linux、Windows 三个构建 job 都注入了它任何一端签名失败都会阻断发布。六、本地跑起来三步快速开始 想自己编译按 README.zh-CN.md 的步骤1. 准备环境Node.js 20、pnpm 10、Rust stable再按系统装 Tauri 前置依赖macOS 装 Xcode 命令行工具、Windows 装 C Build Tools、Linux 装 webkit2gtk。2. 克隆并安装依赖git clone https://gitcode.com/zhukunpenglinyutong/desktop-cc-gui cd desktop-cc-gui pnpm install3. 启动或构建pnpm dev # 开发模式 pnpm build # 前端打包 pnpm build:mac # macOS 签名构建需在 macOS 且有证书总结这套发布体系做对了什么✅版本门禁手动触发 版本号三处比对 tag 查重杜绝误发✅工作区依赖插件 SDK 走workspace:*供应链配置发布年龄门槛、no-downgrade、补丁防投毒✅macOS 合规签名 → 公证 → 装订三步齐全DMG 打包失败自动重试 3 次✅Linux 稳定性裁剪冲突 Wayland 库并重签名✅发布自动化latest.json自动生成、发布说明从提交历史提炼、版本号自动 bump 开 PR。理解这条流水线你也就掌握了 Tauri 桌面应用三平台构建 签名公证 自动更新的完整范式。【免费下载链接】desktop-cc-guiMulti-engine AI coding desktop client (Tauri). Claude Code, Codex, Gemini, OpenCode, DeepSeek Harness and more in one GUI.项目地址: https://gitcode.com/zhukunpenglinyutong/desktop-cc-gui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考