GitHub Actions实战：Morphe-AutoBuilds每日定时流水线patch.yml完整逐段解读指南

Morphe-AutoBuilds 是一个配置驱动的 GitHub Actions 自动化构建流水线，每天 06:00 UTC 定时触发，自动从多个 APK 源下载应用、应用补丁、签名并产出可按需安装的安卓 APK。核心全部逻辑由一份工作流文件 patch.yml 驱动——这篇文章就带你逐段读懂它，学完即可上手搭建自己的每日定时 CI 流水线。

🗺️ 流水线全景：5 个 Job 如何串联

patch.yml 定义了 5 个 job，形成「检查 → 读配置 → 并行构建 → 发布 → 清理」的完整闭环：

这种「用needs+if条件控制任务是否执行」的编排思路，是所有复杂 Actions 流水线的通用范式。

1️⃣ 触发器：定时 + 手动双入口

patch.yml#L6-L15 定义了两种触发方式：

• 定时触发：cron: '0 6 * * *'即每天 UTC 6 点自动执行，这是「每日定时流水线」的起点；
• 手动触发：workflow_dispatch提供force_full_rebuild布尔开关，勾选后忽略增量检查、强制重建所有应用——排查问题或首次铺量时非常有用。

💡 小知识点：GitHub 的 cron 表达式为 5 段（分 时 日 月 周），时区为 UTC。

2️⃣ download-tools：工具缓存的「模板」Job

patch.yml#L18-L53 负责用curl下载 revanced-cli、patches 与 integrations 三个工具，再交给actions/cache@v4写入缓存。

两个值得学习的细节：

• 缓存 key 用内容哈希：key: revanced-tools-${{ hashFiles('patch-config.json', 'arch-config.json') }}——只要两个配置文件不变就命中缓存，一旦配置变更自动失效重建；
• if: ${{ false }}一键禁用：该 job 目前整体被关闭（构建逻辑已改为运行时按需下载），但保留完整步骤作为「工具预取 + 缓存」的标准写法，是 patch.yml 中最容易看懂的一段。

3️⃣ check-updates：增量构建的「大脑」

这是整条流水线最聪明的部分。每天全量重建几十款应用既慢又浪费配额，于是 check-updates job 先跑 scripts/check_app_updates.py 做增量判断：

1. 读取 patch-config.json（95 个 app/source 组合）+ arch-config.json（架构矩阵）展开出完整矩阵；
2. 拉取上一轮发布的manifest.json基线；
3. 对每个条目比对三类信号：配置版本变化、补丁源 Release 签名变化、APK 是否缺失；
4. 输出build_matrix.json（需要重建的）、carry_over.json（沿用旧包的）、new_manifest.json（新基线），并上传为build-plan工件（patch.yml#L108-L117）。

if: needs.check-updates.outputs.has_updates == 'true' # 没更新？下游全部跳过

失败兜底设计也很到位：脚本内部任何异常都会回退到全量重建矩阵（check_app_updates.py#L1018-L1033），宁可多建、不可漏建。

4️⃣ patch-apps：矩阵读取与兜底回退

patch-apps job 本身很短：把上游输出的build_matrix透传给strategy.matrix；若检查阶段输出为空，则回退到jq -c '.patch_list' patch-config.json全量重建——一个典型的防御式编程写法。

5️⃣ build-apps：核心构建 Job 逐段拆解

build-apps 是整个流水线的重头戏，可拆成 6 个知识点：

① 矩阵并行 + 失败隔离

strategy: fail-fast: false # 单个 app 失败不取消兄弟任务 matrix: include: ${{ fromJson(needs.patch-apps.outputs.matrix) }}

矩阵里每行{app_name, source}展开成一个独立并行的 runner，某款应用挂了不会拖垮其他应用。

② FlareSolverr 反爬服务

patch.yml#L146-L151 用services拉起flaresolverr容器（宿主端口 8192 映射容器 8191），专门替下载脚本解决 Cloudflare 验证。随后「Wait for FlareSolverr」步骤用for i in $(seq 1 30)轮询最多 150 秒等它就绪——服务容器就绪 ≠ 立刻可用，这种轮询等待是 services 场景的标准姿势。

③ 环境装配

setup-python@v5装 Python 3.11 与依赖，setup-java@v4装 Temurin JDK 21，actions/cache@v4按相同的hashFileskey 恢复工具缓存，与第 2 节形成闭环。

④ 真正的构建命令

patch.yml#L197-L208 把APP_NAME / SOURCE / ARCH注入环境变量后执行python -m src。入口 src/main.py 会按 arch-config.json 展开架构、从 apps/ 读取应用配置、多源 failover 下载 APK（APKMirror → APKPure → Aptoide → Uptodown…）、按 patches/ 中的+/-规则增删补丁、裁剪架构并用 keystore/public.jks 统一签名。

一个有趣的细节：构建前先sleep $((RANDOM % 30))随机抖动，避免矩阵任务同时开火把下载源限流打爆。

⑤ 构建记账

无论成败（if: always()），record_build.py 都会为每个产出的 APK 写一条 JSON 记录（含从文件名提取的实际版本号），随build-records-*工件上传——这是下一轮增量判断的数据来源。

⑥ 产物工件

actions/upload-artifact@v4按apk-<app>-<source>命名上传*.apk，供发布 job 统一收集。

6️⃣ create-single-release：汇总、合并清单与发布

create-single-release 注意if: always() && ...——即使 build-apps 部分失败也尝试发布成功的那部分，最大化每次运行的产出：

1. download-artifact@v4按pattern: apk-*一次性拉回所有 APK 工件；
2. 用find ... | wc -l检查是否真有产物，没有则置skip_release=true优雅跳过后续步骤；
3. merge_manifest.py 把build-plan/new_manifest.json与各构建记录合并成最终manifest.json，并只在构建成功后把pending_source_sig转正为source_sig——失败的构建不会「消耗」掉一次上游变更，下次运行自动重试，闭环极其严谨；
4. 执行 scripts/gitlab_publish_release.py，以--merge模式上传新 APK 与 manifest、替换latestRelease 资源链接、删除同身份前缀的旧版本 APK，实现「滚动替换」而非堆积归档。

7️⃣ cleanup：给仓库「断舍离」

patch.yml#L358-L370 使用第三方 actionMattraks/delete-workflow-runs@v2，保留最近 3 天、至少 5 次运行记录，防止每天定时任务把 Actions 历史刷屏。if: always()保证清理永远执行。

🧩 总结：值得抄进自己流水线的 6 个设计

配套的 manual-patch.yml 还演示了另一种玩法：通过workflow_dispatch的choice输入框指定 app、架构、版本，做单应用的手动精准构建，两者对照阅读收获更大。

⚠️ 免责声明：本项目仅用于学习与研究自动化构建流水线，仓库本身不包含任何可下载文件；构建产物需自行遵守相关应用与补丁源的许可条款。