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-releasev3 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 页面、填个版本号、点一下运行——剩下的几十个包交给流水线就好。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
