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-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），仅供参考

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

相关推荐

零基础AI漫剧制作全流程：豆包+剪映，无需插件轻松成片

三电平+LCL有源电力滤波器设计：从拓扑选型到现场调试的完整指南

C# dynamic性能实测：用动态绑定取代反射，导出性能提升数倍

更多资讯

Win10下原生部署MSDE 2000实战指南

自动驾驶超车场景下的变时域MPC路径规划实践

高效处理大CSV文件的技术与实践

人大金仓KingbaseES V8R6 Java适配全指南：驱动、连接池与事务避坑

变时域MPC在自动驾驶超车场景中的优化与应用

插入排序、希尔排序、选择排序底层原理与工程选型

今日更新

Agent-Reach：打通大模型触达外部系统的最后一公里

深度学习图像隐写分析实战：从CNN原理到毕设源码全解析

AI赋能知识产权供需匹配：专利评估、需求挖掘与多路召回工程实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？