WSABuilds 自动化构建：用 GitHub Actions 跑通 2 种架构 × 8 种 Root 方案的多架构 CI-育师

WSABuilds 自动化构建：用 GitHub Actions 跑通 2 种架构 × 8 种 Root 方案的多架构 CI

【免费下载链接】WSABuildsRun Windows Subsystem For Android on your Windows 10 and Windows 11 PC using prebuilt binaries with Google Play Store (MindTheGapps) and/or Magisk or KernelSU (root solutions) built in.项目地址: https://gitcode.com/GitHub_Trending/ws/WSABuilds

在 WSABuilds 这个项目里，WSA 构建、持续集成和 GitHub Actions 是绑在一起的：你在 Actions 页面点一次"运行"，几十个不同配置的安装包就会在云端排队产出。

为什么一个"打包脚本"需要一整套流水线

想象你要一个"KernelSU + Pixel 7 型号 + Win10 兼容补丁"的 WSA 安装包：手动流程是先下 WSA 的 WIM 包，再下 KernelSU 和 GApps，解包系统镜像、塞入 Root 方案、改设备参数、重新打包压缩——每一步都是体力活，而且换个配置就要再来一遍。WSABuilds 把这条链整体搬上了 GitHub Actions，它本身是一个用预构建二进制在 Windows 10/11 上运行 WSA 的开源项目，内置 MindTheGapps 与 Magisk、KernelSU 等 Root 方案，而所有定制组合都不再靠人手，全部由自动化打包流水线产出。

触发之后，三条工作流各管一摊

这个仓库的.github/workflows/update.yml是唯一的对外入口，扮演"导演"：WSA 出新版本时，它先检查上游组件有没有更新，再创建发版标签，然后按配置组合逐次"点名"构建。build.yml是"剪辑师"：自己不接收人工触发，只接受参数、吐出货。buildtester.yml则是"审片人"：一个可手动触发的交互界面，让你自己勾选架构、Root 方案、GApps、设备型号，跑一次试验性的构建，用来验证新想法而不污染正式发布。

三者之间的连接靠 reusable workflow 实现，核心就一行：

uses: ./.github/workflows/build.yml # 像调函数一样"调用"整个构建流程 with: arch: x64 # 这一行决定目标 CPU 架构 root: magisk # 这一行决定内置哪种 Root 方案

设计意图很直白：把"构建"当作函数调用。构建逻辑只维护一份，导演新增一个配置组合时，只需加几行 job 声明，而不是复制一整套 YAML。

从参数到产物：一次构建的四个阶段

每个被调起的 build job 内部是同一条时间线。准备阶段：在 Ubuntu 运行器上建 Python 虚拟环境，装好 e2fsprogs、qemu-utils 这类工具——它们是后面修改 ext4 系统镜像的前提。下载阶段：拉取 WSA 的 WIM 包、对应版本的 Magisk 或 KernelSU、GApps 包。构建阶段：核心是MagiskOnWSA/scripts/build.sh，它把镜像解包、装入 Root 方案、替换设备型号，随后再执行 Houdini 安装脚本写入 ARM 二进制翻译组件。后处理阶段：打 Win10 兼容补丁、用 7z 高压缩比打包、生成 SHA256 校验和，最后把产物挂上 Release。

这条时间线真正的难点是组合爆炸：两种架构、若干 Root 选项、GApps 与否、Amazon Appstore 去留、设备型号，叉乘下来是几十个变体。项目的解法不复杂——每个组合一个独立 job 并行跑，job 之间用 needs 声明依赖，全部等导演完成检查与打 tag 后才启动，任何一路失败也不拖累其他路。

./scripts/build.sh --arch x64 --release-type WIF \ --magisk-ver stable --install-gapps \ --root-sol magisk --remove-amazon \ --compress-format none # 全部配置都收敛为脚本参数

让流水线"自己长"：更新检测与发版

发版链路的设计目标是"人只需要等通知"。update.yml 的检查 job 会跑上游版本检查脚本，轮询 Magisk 稳定版与 Canary、KernelSU、MindTheGapps 的最新版本；download links job 则自动把 README 里的下载徽章链接改写为新版本的 Release 地址，省去了人工维护表格的环节。随后 check-and-create-tag job 先逐个查询标签是否已存在以防重名，把版本号和日期填进 Release 说明模板，再对 Windows 11 x64、Windows 11 arm64、Windows 10 x64 三个标签各调一次发版动作：

uses: softprops/action-gh-release@v3 with: tag_name: ${{ env.WIN11X64_TAG }} # 形如 Windows_11_1.27.x 的标签 body_path: Windows11x64.md # 版本说明由模板自动填充

到这里，WSABuilds 自动化打包的最后一环闭合了：从版本变化到三个平台的新 Release 上架，全程无需人工操作。

实际跑起来才知道的坑

磁盘空间是最先撞上的墙。每个构建要同时摆着几 GB 的 WIM 包和展开后的多分区 vhdx 系统镜像，而运行器只有 14GB 磁盘。build.sh 的做法是用 mktemp 建独立临时工作目录，并在脚本退出时用 trap 钩子自动清场，让磁盘峰值只出现在单路构建的生命周期内。

上游下载超时是第二块常见的石头。WSA 的包体积大，官方 CDN 偶尔抽风，整条 job 就白等了十几分钟。好在下载文件都落在固定目录并按清单记录状态，失败后重跑时已完成的文件不会重新拉取，重试的成本基本等于零。

arm64 和 x64 的差异则藏得很深。x64 的 Win10 兼容补丁在 Linux 上就能完成——用 xmlstarlet 改 AppxManifest、替换几个 DLL 即可；但 PRI 资源合并和 vhdx 压缩依赖 Windows 侧的 arm64 版 makepri.exe，所以 buildtester 流程里 build job 先用 cache 把产物递给一个 windows-latest 运行器收尾，跨系统交接靠的就是这一来一回。另有一条硬规则：Win10 补丁根本不支持 arm64，输入校验会在流水线入口直接拦下这个非法组合，而不是让它跑到一半才报错。

下次看到 WSA 新版本号发布时，你要做的只剩打开 Actions 页面、填个版本号、点一下运行——剩下的几十个包，交给流水线就好。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考