从触发到安装包看懂 WSABuilds 的 GitHub 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/WSABuildsWSABuilds 持续集成方案的核心是仓库 .github/workflows/ 目录下的一组 GitHub Actions 自动化构建工作流它能在无人值守的情况下为 Windows 10/11 上的安卓子系统WSA批量生产带 Google Play 服务、Magisk 或 KernelSU _root 方案的定制安装包。对你来说这意味着不用自己拼凑组件、不用手动改镜像——你只需要在 Actions 界面点几下鼠标剩下的下载、打包、压缩、发版全部自动完成。三个工作流各司其职先看整体分工。这套自动化由三个 YAML 工作流文件组成每个文件只干一件事。build.yml是主构建流程它本身不做触发而是作为一个可复用工作流reusable workflow即一个可以被别的 workflow 像调用函数一样引用的工作流被参数化调用x64 与 arm64 架构、Magisk/KernelSU/无 Root 各种组合最终都落到它身上。update.yml负责发布日检查 Magisk、KernelSU、MindTheGapps 三个上游组件有没有新版本更新仓库里的版本文件与 README 下载链接创建 Release 标签然后把十几个构建任务扇出去并行执行。buildtester.yml则是给你用的手动入口用于测试性质的自定义构建。这个分法的好处很直接主构建逻辑只维护一份。update.yml 里每个构建任务都长这样- uses: ./.github/workflows/build.yml with: arch: x64 root: magisk devicemodel: redfin改一处构建逻辑所有配置组合同步生效不需要在每个 job 里重复维护几十行相同的步骤。一次构建的完整旅程从触发到安装包下面按顺序走一遍单次构建经历的四步这也是你排查问题时该对号入座的位置。第一步环境准备。工作流先在 Ubuntu 运行器上用 actions/setup-python 装好 Python 并按MagiskOnWSA/scripts/目录配置 pip 依赖缓存接着创建 Python 虚拟环境再安装 e2fsprogs、attr、unzip、qemu-utils 这类处理磁盘镜像所需系统包。第二步组件下载。构建脚本自动拉取 WSA 官方核心组件、对应分支的 Magisk 或 KernelSU 包以及 Play 服务GApps安装包。Insider 渠道还需要你提前填好 user code脚本会把它写进下载凭证文件。第三步构建处理。所有重活集中在 MagiskOnWSA/scripts/build.sh它会解包 WSA 镜像、写入 root 方案、安装 GApps、按需替换设备型号并把 32 位应用所需的 Houdini 二进制翻译器让 arm32 应用能在 arm64 子系统里运行的翻译层装进系统。第四步后处理。这部分在 Windows 运行器上完成先用 makepri 合并语言与密度资源再用 diskpart 对 system、product、system_ext、vendor 四个 .vhdx 镜像分区做离线压缩瘦身目标是 Windows 10 时还会用 PowerShell 补丁修改 AppxManifest.xml 中的最低系统版本并替换 winhttp.dll 等兼容文件。最后用 7z 的 LZMA2 高压缩参数打包生成 sha256-checksum.txt 校验和上传为构建产物。这里的关键是跨系统接力Linux 机器产出中间产物后通过 actions/cache 的 save/restore 把目录递给 Windows 机器继续加工两个平台各干自己擅长的部分。参数矩阵一套流水线怎么产出多种包可复用工作流的威力体现在参数组合上。你只需选四个维度的值流水线就会拼出对应的包archx64 或 arm64决定目标 CPU 架构root_solNon-root、KernelSU或 Magisk 的 Stable/Beta/Canary/Debug/Alpha/Delta 各分支gapps_brandMindTheGapps v13.0 或 No GAppscustom_modelWSA 默认以及 Pixel 4a 到 Pixel Fold 等一系列机型代号比如选 Pixel 5实际传给脚本的是代号redfin这样部分应用的机型检测会更像真机update.yml 里x64/arm64 × 无 Root/KernelSU/Magisk/Magisk Canary × 含/不含 GApps × 保留/移除 Amazon 商店的组合被摊平成一个个独立 job每个 job 声明needs依赖后同时启动。多配置并行构建让一次 WSA 版本更新能在一次运行里铺满整个矩阵而所有 job 共享同一份 build.yml 逻辑维护成本只有一份。自动盯梢版本更新是怎么自己跑起来的上游组件一旦发新版仓库不会自己知道——靠的是 MagiskOnWSA/Update Check/ 目录下的四个检查脚本MagiskStableUpdateCheck.py、MagiskCanaryUpdateCheck.py、KernelSUUpdateCheck.py和MTGUpdateCheck.py。它们分别爬取 Magisk 稳定版、Canary 版、KernelSU 与 MindTheGapps 的发布页比对当前仓库记录的版本发现新版纳入环境变量。update.yml的 check 任务依次运行这四个脚本把结果提交到独立的update分支更新 .appversion 版本文件随后update-downloadlinks.py按 WIF 或 retail 渠道刷新 README 里的下载徽章链接。再往后工作流先用 tag-exists-action 确认Windows_11_x.x之类的新标签不存在避免重复发版再把检查到的各组件版本填进 Release 说明模板的占位符如 Magisk 版本号、MindTheGapps 包名最后用 softprops/action-gh-release 一步创建标签和 Release 页。动手环节手动触发一次自定义构建想给自己打个定制包流程如下打开仓库 Actions 页面选择名为 Custom Build (for testing purpose) 的工作流点 Run workflow然后按表单填参数即可——目标 Windows 版本10 或 11、CPU 架构、WSA 发行渠道Retail 到 Insider 各档、Root 方案、GApps、Pixel 机型、压缩格式.7z 或 .zip以及是否移除 Amazon 商店。这就是 Magisk WSA 手动构建的全部操作通常十几分钟后就能在构建产物里拿到安装包。有一个硬性限制要先记住Windows 10 兼容性补丁不支持 arm64所以Windows 10 arm64这个组合会在第一步输入校验处直接失败退出属于预期行为不必排查网络。更快更稳缓存、并行与常见故障排查速度方面有三层设计。依赖层面actions/setup-python 开启 pip 缓存系统包层面用 cache-apt-pkgs-action 缓存 e2fsprogs 等 apt 包避免每次运行重复下载调度层面矩阵里的构建 job 彼此并行产物层面7z 采用-mx6 -m0LZMA2参数配合多线程压缩兼顾包体积与耗时。遇到构建失败先查这三处一是输入校验步骤的日志参数组合是否被规则拦下二是 Python 虚拟环境与 requirements.txt 依赖安装段失败多半是依赖解析问题三是 MagiskOnWSA/scripts/ 中 build.sh 的下载与构建日志组件源偶发超时是最常见的真凶重跑通常即可恢复。延伸阅读全部工作流配置.github/workflows/核心构建脚本MagiskOnWSA/scripts/build.sh上游更新检查脚本MagiskOnWSA/Update Check/本地更新脚本WSAUpdater.pyWSABuilds Utilities/Update Script/安装包使用与安装文档Documentation/WSABuilds/Installation.md【免费下载链接】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 自动化构建
从触发到安装包看懂 WSABuilds 的 GitHub 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/WSABuildsWSABuilds 持续集成方案的核心是仓库 .github/workflows/ 目录下的一组 GitHub Actions 自动化构建工作流它能在无人值守的情况下为 Windows 10/11 上的安卓子系统WSA批量生产带 Google Play 服务、Magisk 或 KernelSU _root 方案的定制安装包。对你来说这意味着不用自己拼凑组件、不用手动改镜像——你只需要在 Actions 界面点几下鼠标剩下的下载、打包、压缩、发版全部自动完成。三个工作流各司其职先看整体分工。这套自动化由三个 YAML 工作流文件组成每个文件只干一件事。build.yml是主构建流程它本身不做触发而是作为一个可复用工作流reusable workflow即一个可以被别的 workflow 像调用函数一样引用的工作流被参数化调用x64 与 arm64 架构、Magisk/KernelSU/无 Root 各种组合最终都落到它身上。update.yml负责发布日检查 Magisk、KernelSU、MindTheGapps 三个上游组件有没有新版本更新仓库里的版本文件与 README 下载链接创建 Release 标签然后把十几个构建任务扇出去并行执行。buildtester.yml则是给你用的手动入口用于测试性质的自定义构建。这个分法的好处很直接主构建逻辑只维护一份。update.yml 里每个构建任务都长这样- uses: ./.github/workflows/build.yml with: arch: x64 root: magisk devicemodel: redfin改一处构建逻辑所有配置组合同步生效不需要在每个 job 里重复维护几十行相同的步骤。一次构建的完整旅程从触发到安装包下面按顺序走一遍单次构建经历的四步这也是你排查问题时该对号入座的位置。第一步环境准备。工作流先在 Ubuntu 运行器上用 actions/setup-python 装好 Python 并按MagiskOnWSA/scripts/目录配置 pip 依赖缓存接着创建 Python 虚拟环境再安装 e2fsprogs、attr、unzip、qemu-utils 这类处理磁盘镜像所需系统包。第二步组件下载。构建脚本自动拉取 WSA 官方核心组件、对应分支的 Magisk 或 KernelSU 包以及 Play 服务GApps安装包。Insider 渠道还需要你提前填好 user code脚本会把它写进下载凭证文件。第三步构建处理。所有重活集中在 MagiskOnWSA/scripts/build.sh它会解包 WSA 镜像、写入 root 方案、安装 GApps、按需替换设备型号并把 32 位应用所需的 Houdini 二进制翻译器让 arm32 应用能在 arm64 子系统里运行的翻译层装进系统。第四步后处理。这部分在 Windows 运行器上完成先用 makepri 合并语言与密度资源再用 diskpart 对 system、product、system_ext、vendor 四个 .vhdx 镜像分区做离线压缩瘦身目标是 Windows 10 时还会用 PowerShell 补丁修改 AppxManifest.xml 中的最低系统版本并替换 winhttp.dll 等兼容文件。最后用 7z 的 LZMA2 高压缩参数打包生成 sha256-checksum.txt 校验和上传为构建产物。这里的关键是跨系统接力Linux 机器产出中间产物后通过 actions/cache 的 save/restore 把目录递给 Windows 机器继续加工两个平台各干自己擅长的部分。参数矩阵一套流水线怎么产出多种包可复用工作流的威力体现在参数组合上。你只需选四个维度的值流水线就会拼出对应的包archx64 或 arm64决定目标 CPU 架构root_solNon-root、KernelSU或 Magisk 的 Stable/Beta/Canary/Debug/Alpha/Delta 各分支gapps_brandMindTheGapps v13.0 或 No GAppscustom_modelWSA 默认以及 Pixel 4a 到 Pixel Fold 等一系列机型代号比如选 Pixel 5实际传给脚本的是代号redfin这样部分应用的机型检测会更像真机update.yml 里x64/arm64 × 无 Root/KernelSU/Magisk/Magisk Canary × 含/不含 GApps × 保留/移除 Amazon 商店的组合被摊平成一个个独立 job每个 job 声明needs依赖后同时启动。多配置并行构建让一次 WSA 版本更新能在一次运行里铺满整个矩阵而所有 job 共享同一份 build.yml 逻辑维护成本只有一份。自动盯梢版本更新是怎么自己跑起来的上游组件一旦发新版仓库不会自己知道——靠的是 MagiskOnWSA/Update Check/ 目录下的四个检查脚本MagiskStableUpdateCheck.py、MagiskCanaryUpdateCheck.py、KernelSUUpdateCheck.py和MTGUpdateCheck.py。它们分别爬取 Magisk 稳定版、Canary 版、KernelSU 与 MindTheGapps 的发布页比对当前仓库记录的版本发现新版纳入环境变量。update.yml的 check 任务依次运行这四个脚本把结果提交到独立的update分支更新 .appversion 版本文件随后update-downloadlinks.py按 WIF 或 retail 渠道刷新 README 里的下载徽章链接。再往后工作流先用 tag-exists-action 确认Windows_11_x.x之类的新标签不存在避免重复发版再把检查到的各组件版本填进 Release 说明模板的占位符如 Magisk 版本号、MindTheGapps 包名最后用 softprops/action-gh-release 一步创建标签和 Release 页。动手环节手动触发一次自定义构建想给自己打个定制包流程如下打开仓库 Actions 页面选择名为 Custom Build (for testing purpose) 的工作流点 Run workflow然后按表单填参数即可——目标 Windows 版本10 或 11、CPU 架构、WSA 发行渠道Retail 到 Insider 各档、Root 方案、GApps、Pixel 机型、压缩格式.7z 或 .zip以及是否移除 Amazon 商店。这就是 Magisk WSA 手动构建的全部操作通常十几分钟后就能在构建产物里拿到安装包。有一个硬性限制要先记住Windows 10 兼容性补丁不支持 arm64所以Windows 10 arm64这个组合会在第一步输入校验处直接失败退出属于预期行为不必排查网络。更快更稳缓存、并行与常见故障排查速度方面有三层设计。依赖层面actions/setup-python 开启 pip 缓存系统包层面用 cache-apt-pkgs-action 缓存 e2fsprogs 等 apt 包避免每次运行重复下载调度层面矩阵里的构建 job 彼此并行产物层面7z 采用-mx6 -m0LZMA2参数配合多线程压缩兼顾包体积与耗时。遇到构建失败先查这三处一是输入校验步骤的日志参数组合是否被规则拦下二是 Python 虚拟环境与 requirements.txt 依赖安装段失败多半是依赖解析问题三是 MagiskOnWSA/scripts/ 中 build.sh 的下载与构建日志组件源偶发超时是最常见的真凶重跑通常即可恢复。延伸阅读全部工作流配置.github/workflows/核心构建脚本MagiskOnWSA/scripts/build.sh上游更新检查脚本MagiskOnWSA/Update Check/本地更新脚本WSAUpdater.pyWSABuilds Utilities/Update Script/安装包使用与安装文档Documentation/WSABuilds/Installation.md【免费下载链接】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），仅供参考