云端打包流程——GitHub Actions 在背后做了什么

一键发布背后的流水线

在 PakePlus 配置页面点"发布"按钮，触发的不是一个本地编译过程，而是一串 GitHub 上的自动化动作：

flowchart LR
  A[点发布按钮] --> B[PakePlus 客户端]
  B --> C{你自己的 fork 仓库}
  C --> D[触发 GitHub Actions]
  D --> E[Windows Runner 编译]
  D --> F[macOS Runner 编译]
  D --> G[Linux Runner 编译]
  E --> H[.exe / .dmg / .deb]
  F --> H
  G --> H
  H --> I[上传到 GitHub Release]
  I --> J[PakePlus 通知你打包完成]

第 1 步：PakePlus 客户端同步配置

点发布按钮后，PakePlus 本地客户端做的第一件事是：

1. 读取当前项目的所有配置（APP 名称、网站地址、窗口模式、图标、JS 注入脚本等）
2. 读取你可能上传的 dist 静态文件
3. 通过 GitHub API（用你的 Token）把这些内容 push 到你 fork 出来的模板仓库的某个分支
4. 推送完成后触发 GitHub Actions workflow

这一步完成很快（几秒钟），瓶颈在 dist 文件大小和 GitHub API 响应速度。

第 2 步：GitHub Actions 接收事件

你的 fork 仓库里预设了一套 .github/workflows/*.yml 文件——这是 PakePlus 模板自带的。当 PakePlus push 上来后，GitHub 自动：

1. 检测到推送事件
2. 触发 workflow 执行
3. 并行启动多个 Runner（Windows / macOS / Linux）

GitHub Actions 的免费额度

大多数 PakePlus 打包一次用 2-5 分钟，2000 分钟足够每月打 400-1000 次。

第 3 步：各 Runner 并行编译

每个 Runner 做的事情：

Windows Runner

1. windows-latest（Windows Server 2022，含 x64 和 ARM64）
2. 安装 Rust toolchain
3. 安装 Tauri CLI
4. 读取 fork 仓库里的项目配置
5. 编译出 .exe 安装包 + 绿色免安装版
6. 可选：打包 Win7 兼容版

macOS Runner

1. macos-latest（Apple Silicon）+ macos-13（Intel）
2. 分别编译 Apple Silicon 和 Intel 二进制
3. 合成通用二进制（Universal Binary）
4. 打包成 .dmg

Linux Runner

1. ubuntu-latest（x64）+ ubuntu-22.04-arm（ARM64，模拟）
2. 安装 WebKitGTK 等编译依赖
3. 编译出 .deb 和 .AppImage
4. 可选：打包统信/麒麟专用版本

移动端额外步骤

如果需要 Android/iOS，还有额外的编译步骤：

• Android：安装 Android NDK → 用 Gradle 编译 APK
• iOS：安装 Xcode → 用原生框架编译 IPA

第 4 步：产物上传到 GitHub Release

所有 Runner 编译完成后，产物统一上传到 GitHub 的 Release 页面：

• Release 自动创建（以版本号命名）
• 每个产物作为一个 Asset 上传
• Release 页面公开可访问

用户最终在 GitHub Release 页面看到的就是这样一个页面：所有平台的安装包按文件名排列，点哪个下哪个。

第 5 步：PakePlus 通知

PakePlus 客户端会轮询 GitHub API 查询 Actions 运行状态，或者通过 webhook 接收通知：

• 进行中 → 显示进度条和百分比
• 成功 → 显示"打包完成"并跳转到 Release 页面
• 失败 → 显示错误日志，引导排查

常见失败原因

耗时估算

为什么不本地编译

云端编译的核心优势是：本地什么都不用装。Rust toolchain 下载安装（几百 MB）、Tauri CLI 安装、WebKitGTK 依赖……这些全部由 GitHub Actions Runner 自动搞定。用户只需要那个 10MB 的 PakePlus 客户端。