起因

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

然后，我在想安卓这边每次更新都需我自己在本地编译 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：January 6th, 2021 at 05:15 pm
© 允许规范转载
要饭啦~