利用Github Action实现APK自动化构建与发布全流程

1. 为什么你需要一个“自动打包机器人”？

如果你是一个Android开发者，或者在一个移动开发团队里，你一定经历过这样的场景：产品经理催着要一个测试包，你手忙脚乱地在本地电脑上点击“Build APK”，然后等待漫长的编译过程，最后再把那个几十兆甚至上百兆的文件，通过聊天软件或者网盘，小心翼翼地发给测试同事。这还没完，测试同事可能会反馈：“这个包怎么和昨天那个版本号一样？” 或者，“这个包是debug版还是release版？” 一来二去，宝贵的时间都浪费在沟通和手动操作上了。

更头疼的是，当团队协作时，每个人的本地环境可能略有不同，你本地能编译通过的代码，到了同事那里可能就报错了。这种“在我机器上是好的”问题，是团队协作中典型的效率杀手。

其实，你完全可以把这个重复、枯燥且容易出错的打包工作，交给一个不知疲倦的“机器人”去做。这个机器人就是 Github Action。它就像你安插在云端的一个全能助手，只要你把代码推送到Github仓库，它就能自动帮你完成编译、测试、打包，甚至把最终生成的APK文件，整整齐齐地发布到项目的Release页面，供所有人下载。

我刚开始接触这个概念时也觉得有点“高大上”，但实际用下来才发现，它带来的效率提升是颠覆性的。以前手动打包一次可能要10-20分钟，现在代码一提交，我就可以去喝杯咖啡，回来就能在Release页面看到热乎的安装包了。测试同学也能随时获取到对应提交的最新构建，沟通成本几乎降为零。这篇文章，我就想把我从零开始搭建这套自动化流程的经验、踩过的坑，以及一些让流程更稳的配置技巧，毫无保留地分享给你。即使你之前没接触过CI/CD，跟着步骤走，一个小时也能搞定。

2. 动手之前：理解Github Action的核心概念

在开始写代码之前，我们得先搞清楚Github Action到底是怎么玩的。别被那些YAML配置文件吓到，它的逻辑其实非常直观。你可以把它想象成一个乐高积木搭建的流水线。

首先，最核心的文件是存放在你项目根目录 .github/workflows/ 下的一个YAML文件，比如我们叫它 build-and-release.yml。这个文件就是告诉Github Action：“当我触发某个事件时，请按照我写的步骤去执行。”

那么，什么事件能触发这条流水线呢？最常见的就是 代码推送（push）。比如，你把代码推送到 main 分支，或者推送到一个带版本号的标签（tag），流水线就会自动启动。你也可以配置在创建 拉取请求（pull request） 时触发，这样在代码合并前就能自动跑一遍编译和测试，确保新代码不会“搞坏”主分支。

一个完整的流水线（workflow）由一个或多个 任务（job） 组成。任务之间可以是独立的，也可以有依赖关系。比如，我们可以设计两个任务：第一个任务 build 负责编译APK；第二个任务 release 负责发布，并且它需要等待 build 任务成功完成后才能开始。这样设计的好处是职责清晰，也方便排查问题。

每个任务里，则是一系列按顺序执行的 步骤（step）。步骤是真正干活的地方。一个典型的APK构建任务可能包含这些步骤：

1. 拉取代码到虚拟服务器。
2. 设置Java开发环境。
3. 赋予Gradle脚本执行权限。
4. 执行Gradle打包命令。
5. 把打包好的APK文件存为“工件（artifact）”，供后续步骤或其他任务使用。

Github Action的强大之处在于，它有一个官方和社区维护的 “动作（action）” 市场。这些“动作”就是封装好的、可复用的步骤模块。比如，你不用自己写命令去安装Java，直接用 actions/setup-java@v3 这个动作，指定版本号就行。这就像给你的流水线安装了一个个现成的、功能强大的“乐高模块”，极大地简化了配置。

最后，Github Action的流水线运行在Github提供的 虚拟服务器（runner） 上。最常用的是 ubuntu-latest，一个干净的Ubuntu Linux环境。每次流水线启动，都会创建一个全新的虚拟环境，这从根本上解决了“在我机器上是好的”这个问题，保证了构建环境的一致性。

3. 从零开始：编写你的第一个构建工作流

理论说再多不如动手试一次。我们现在就来创建一个最简单的、只构建APK的工作流。打开你的Android项目，在根目录创建文件夹 .github/workflows，然后在这个文件夹里新建一个文件，命名为 build-apk.yml。

3.1 定义工作流的触发条件

我们先从文件头开始。这部分决定了工作流何时运行。

name: Build APK

on:
  push:
    branches: [ "main", "develop" ]
  pull_request:
    branches: [ "main" ]

• name: 给你的工作流起个名字，在Github Actions页面会显示。
• on: 触发事件。
  • push: 当代码推送到 main 或 develop 分支时触发。
  • pull_request: 当向 main