起因

社团的后台仓库具有自动部署脚本,当有推送的时候就可以自动部署到服务器上面,十分便捷。

然后,我在想安卓这边每次更新都需我自己在本地编译 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神器,可以减少我们负担,让我们更专注在代码上面。

Last modification:August 25th, 2020 at 10:09 am
要饭啦~