博客

用 GitHub Actions 在线打包网站应用

打包应用 · 2026年10月17日 · 约 6 分钟

Fork tw93/Pake，打开 Actions，运行 Build App With Pake CLI，填上网站地址和应用名称，再到这次运行的 Artifacts 里下载做好的应用，全程不需要本地的 Rust 工具链。记得在三天内下载，这个工作流的产物只保留这么久。

这个工作流实际做了什么

工作流定义在 Pake 仓库的 .github/workflows/pake-cli.yaml 里。点 Run workflow 以后，GitHub 会起一台你选的系统类型的全新虚拟机，检出你的 fork，装好 Node.js 和 pnpm，构建 Pake CLI，再用表单里的值运行它，大致等于 node dist/cli.js <网址> --name <名称> 加上可选参数，打好的应用作为工作流产物上传。你的电脑上什么都不会装，仓库里也不会写入任何东西，工作流只申请了只读的仓库权限。

这解释了最先会碰到的两个限制。运行器是 GitHub 机房里的一台机器，只能访问公网能访问的东西，localhost 指的是运行器自己，内网的私有地址也可能连不上。表单只接收网站网址，没办法把你磁盘上的本地文件交给它，本地文件见打包本地 HTML。

跑第一次构建

1. 把 tw93/Pake fork 到自己的账号下，打开 fork 的 Actions 标签页，GitHub 询问的话就启用工作流。
2. 在左边列表里选 Build App With Pake CLI，再打开 Run workflow。
3. 填表单，下面是工作流文件里定义的输入项。

1. 点 Run workflow，打开新出现的这次运行，等构建和上传步骤结束。

第一次测试时，除了平台、网址和名称，其余都保持默认。GitHub Actions 在线打包页面有表单的截图，表单背后每个选项的含义见命令行参数。

第一次运行会比较久。Pake 的指南给出的数字是，第一次要建立依赖缓存，大约 10 到 15 分钟，之后用缓存大约 5 分钟，缓存总共 400 到 600 MB。工作流文件里每个构建步骤另外设了 25 分钟的超时。

下载产物，不要下载仓库压缩包

运行显示绿色对勾后，打开它的摘要页，找到 Artifacts。产物的名字由工作流决定，<名称>-macOS 里是 DMG，<名称>-Windows 里是 MSI，Linux 上则是 <名称>-Linux-deb、<名称>-Linux-AppImage 这样分开的几个。下载你系统对应的那个再解压，上传步骤会把每个产物打成 zip。

有两个细节容易漏掉。读取工作流产物需要仓库的读取权限，在自己的 fork 里当然有（见 GitHub 的说明）。另外 GitHub 默认保留 90 天，这个工作流却设了 retention-days: 3，所以周五回来找周一的那次运行，可能已经没有可下载的东西了。需要的文件当场保存，或者重新跑一遍。

同一份说明还提到，习惯命令行的话可以用 gh run download RUN_ID。

绿色对勾能说明什么，不能说明什么

绿色对勾只表示 Pake 构建并上传了一个安装包。它不能说明网站的登录在内嵌网页视图里能用，不能说明应用适合你的 CPU 架构，也不能说明它已经签名和公证、可以对外分发，下载后仍要检查签名和公证状态，并在目标系统上实际测试。Google 等服务商无论加什么参数都可能拒绝内嵌视图里的登录（见登录排查）。

在自己的仓库里用 Pake Action

想把打包放进自己项目的构建流程，仓库还发布了 Pake Action，最小的写法如下。

name: Build Web App
on: [workflow_dispatch]

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: tw93/Pake@v3
        with:
          url: "https://example.com"
          name: "MyApp"

它的输入有 url、name、output-dir（默认 dist）、icon、width、height 和 debug，结果通过 package-path 输出。输出和表单工作流不同，macOS 上是 .app 目录，Windows 上是 .msi，Linux 上是 .deb、.rpm 或 .AppImage。每次运行会把 CLI 这次生成的唯一一个安装包移到输出目录，同一格式出现两个包时这一步会失败（见 Pake Action）。要保留文件，就自己加一个 actions/upload-artifact 步骤，保留天数也由你自己定。

运行失败时

先打开第一个失败的步骤，读它的报错，再决定要不要重跑。常见原因各不相同，处理办法也不同。

• 网址写错、连不上或者是私有地址，改用公网地址。
• 图标网址取不到，留空或者换一个能访问的图片。
• 日志靠前的位置出现依赖或工具链失败，先重跑一次，再按平台查 Pake 常见问题。
• 所有步骤都没开始就停了，问题多半在账号，比如计费问题让 Actions 用量被拦下，和 Pake 无关。

在线打包指南建议构建失败时清掉 Actions 缓存再重试，这一步放在你有理由怀疑缓存之后，不要当成第一步。

什么时候换别的办法

在本机没有的平台上给公开网站打包，Actions 很合适。普通的 Mac 或 Windows 应用，桌面版同样不需要编译器，第一次构建的缓存建好以后，在本机装 Pake CLI 会更快。

常见问题

一定要 fork 吗

工作流要在你自己能控制的仓库里运行，最简单的就是 fork tw93/Pake 并启用 Actions，用 Pake Action 的话可以放在任何仓库里。

能同时构建 Apple 芯片和 Intel 版本吗

在表单里勾上 Universal binary (macOS only)。不勾时构建不是通用版本，CLI 文档说明它会检测要构建的架构。

Windows 安装包在哪

在 <名称>-Windows 产物里，是一个 .msi。

能这样构建本地文件吗

不能，表单只接收网站网址，磁盘上的文件请在本地用 Pake CLI。