起因
社团的后台仓库具有自动部署脚本,当有推送的时候就可以自动部署到服务器上面,十分便捷。
然后,我在想安卓这边每次更新都需我自己在本地编译 release
版本的包,然而编译要花费很长的时间的。于是我在想为什么不利用 github action
来实现 flutter
自动打包功能呢?
github action 是什么
GitHub Actions 是 GitHub 的持续集成服务,于 2018 年 10 月推出。
至于持续集成是什么,自行百度好了。虽然之前听说过 github action
,但是一直觉得这个功能没啥用处,也就是说,我全是自己手动更新服务的。现在看了,自己还是 too young, too simple
。
持续集成由很多操作组成,比如抓取代码、运行测试、登录远程服务器,发布到第三方服务等等。GitHub 把这些操作就称为 actions。
每个 action 就是一个独立脚本,因此可以做成代码仓库,使用 userName/repoName 的语法引用 action。比如,actions/setup-node 就表示 github.com/actions/setup-node 这个仓库,它代表一个 action,作用是安装 Node.js。事实上,GitHub 官方的 actions 都放在 github.com/actions 里面。
这里我们可以看到 action
的强大之处,它可以作为一个仓库被别人引用,可以想到 action
市场有多丰富。
在使用 action
之前我们还是有必要了解一些基本概念。
基本概念
GitHub Actions 有一些自己的术语。
- workflow (工作流程):持续集成一次运行的过程,就是一个 workflow。
- job (任务):一个 workflow 由一个或多个 jobs 构成,含义是一次持续集成的运行,可以完成多个任务。
- step(步骤):每个 job 由多个 step 构成,一步步完成。
- action (动作):每个 step 可以依次执行一个或多个命令(action)。
workflow 文件
GitHub Actions 的配置文件叫做 workflow 文件,存放在代码仓库的.github/workflows 目录。
workflow 文件采用 YAML 格式,文件名可以任意取,但是后缀名统一为.yml,比如 foo.yml。一个库可以有多个 workflow 文件。GitHub 只要发现.github/workflows 目录里面有.yml 文件,就会自动运行该文件。
关于 yaml
文件我接触不是很多,可以参考YAML 语言教程
字段
- name
workflow 的名称,可省略。
- on
执行 workflow
的条件,例如 on: push
,当有 push
时就执行。
- jobs.<job_id>.name
workflow 文件的主体是 jobs 字段,表示要执行的一项或多项任务。
jobs 字段里面,需要写出每一项任务的 job_id,具体名称自定义。job_id 里面的 name 字段是任务的说明。
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
- jobs.<job_id>.needs
needs 字段指定当前任务的依赖关系,即运行顺序。
- jobs.<job_id>.runs-on
runs-on: ubuntu-latest
- jobs.<job_id>.steps
name: Greeting from Mona
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- name: Print a greeting
env
MY_VAR: Hi there! My name is
FIRST_NAME: Mona
MIDDLE_NAME: The
LAST_NAME: Octocat
run: |
echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.
实战
上面是关于 github action
的基础知识,下我们进入实战部分吧。
我们的需求
- 有 push 的时候执行
打包
,之后我们可以下载打包好的 app 以供测试。
为什么,没有自动测试? 懒加上测试代码不好写。
- 自动发布
release版本
根据需求我们可以写出下面的代码
name: push-build
on:
push:
branches: # 这里对分支进行限制,仅仅build master分支,可以减少不必要的action
- master
jobs:
build:
runs-on: ubuntu-18.04 # 环境,无所谓
steps:
- uses: actions/checkout@v1
- uses: actions/setup-java@v1 # flutter 需要java环境
with:
java-version: "12.x"
- uses: subosito/flutter-action@v1 # 搭建 flutter 环境
with:
channel: "stable" # 稳定第一
- run: flutter pub get
# - run: flutter test # 这里没有写测试代码,所以注释掉。
- run: flutter build apk --debug # 由于需要测试,这里生成debug版本的
# 将上一步打包好的文件上传到github上,以供下载
- name: upload artifects
uses: actions/upload-artifact@main
with:
name: android-app
path: build/app/outputs
上述文件,实现了当 master
分支有推送内容时,进行 app build
。
name: release
on:
push:
tags:
- "release-*"
jobs:
release-to-gitHub:
name: release
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- uses: actions/setup-java@v1
with:
java-version: "12.x"
- uses: subosito/flutter-action@v1
with:
channel: "stable"
- run: flutter pub get
# - run: flutter pub deps
# - run: flutter analyze --no-pub --no-current-package lib/ test/
# - run: flutter test --no-pub test/
- run: flutter build apk --target-platform android-arm,android-arm64,android-x64 --split-per-abi
- uses: softprops/action-gh-release@v1
with:
files: build/app/outputs/apk/release/*.apk
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
这里,实现当有以 release
开头的 tag
推送时候,自动生成 release
。
总结
有了 github action
神器,可以减少我们负担,让我们更专注在代码上面。