用 Github Action 自动发布二进制包

崔秀龙

最近更新于 2021 年 9 月 19 日 3 分钟阅读时长原创

Github Actions 是 Github 提供的一个自动化流程工具，编写一段 YAML，随代码一起发布，根据脚本中定义的触发事件，能够完成 Lint、Build、Push Image 等等操作，在 Actions Market 中包含数千个功能各异的项目，能够给软件作者很大的帮助。

在发布 Github 项目版本时，Golang 之类的项目往往都需要执行构建、打包等动作，除了自己动手之外，也可以用 Github Action（也不排除使用 Travis CI 等自动化服务）来完成任务。

定义触发条件

Github Action 是使用 Github 事件来触发的，我们现在的需求是在生成 Release 的时候完成任务，因此可以如此定义触发事件：

on:
  release:
    types:
    - created

Release 相关事件除了 created 之外，还包括 published、unpublished、edited、deleted, 以及 prereleased。对象详情请参看附录 Reference 链接。

交叉构建

确定触发条件之后，下一个任务就是构建了，golang 项目通常需要进行多平台的交叉编译，在 Github Action 中可以用 Matrix 特性做个循环：

    strategy:
      matrix:
        include:
          - goarch: amd64
            goos: linux
          - goarch: amd64
            goos: darwin
          - goarch: arm64
            goos: linux
          - goarch: arm64
            goos: darwin
    steps:
    - uses: actions/checkout@master
    - name: Set up Go
      uses: actions/setup-go@v2
      with: 
        go-version: 1.16
    - name: Making kubectl-karmada
      run: make kubectl-karmada
      env:
        GOOS: ${{ matrix.goos }}
        GOARCH: ${{ matrix.goarch }}

这里针对 arm64、amd64 和 Linux、Darwin 的组合进行了交叉编译：

使用 checkout@master 获取代码
setup-go@v2 设置 golang 环境，并在 with 字句中指定了 1.16 版本
make 这里使用了 Matrix 定义的变量，循环构建每个组合；

打包上传

完成构建之后，对生成的文件进行打包，并进行上传：

    - name: Packaging...
      run: tar czf kubectl-karmada-${{ matrix.goos }}-${{ matrix.goarch }}.tgz kubectl-karmada LICENSE
    - name: Uploading assets...
      if: ${{ !env.ACT }}
      id: upload-release-asset 
      uses: actions/upload-release-asset@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        upload_url: ${{ github.event.release.upload_url }}
        asset_path: ./kubectl-karmada-${{ matrix.goos }}-${{ matrix.goarch }}.tgz
        asset_name: kubectl-karmada-${{ matrix.goos }}-${{ matrix.goarch }}.tgz
        asset_content_type: application/gzip

上传这里用 actions/upload-release-asset@v1 镜像来完成任务。其中用到的事件变量为 github.event.release.upload_url，代表触发事件的 Release 的上传地址。

本地调试

上面的构建过程中有个执行条件 if: ${{ !env.ACT }}，环境变量中不存在 ACT 的时候才执行这个步骤，这个定义是用来做什么的？

Action 比较复杂的时候，调试就成了难题。要做线上操作，才能生成 Github 事件，才能触发 Action，这个过程的效率明显是很难提高的。nektos/act 就能部分地解决这个问题。Act 使用 Docker 环境模拟 Github 的运行环境，能够方便地在本地进行调试，能够减少很多对 Github 远程环境的操作。下面简单地试用一下。

在 Mac 下面可以用 brew install act 进行安装；Linux 下，则可以在命令行中输入 curl https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash。注意前面说到，Act 是依赖 Docker 的，使用之前必须安装 Docker。

输入 act --help 能看到命令的帮助内容，其中有几个重要的选项：

-n：Dry run，用于校验语法，查看基本运行逻辑；
-j：直接指定触发 Job；
g：图形化的方式来展示 Action 的流程；

-e：可以编写一个 JSON 文件来描述 Github 事件，例如一个 PR：

{
  "pull_request": {
    "head": {
      "ref": "sample-head-ref"
    },
    "base": {
      "ref": "sample-base-ref"
    }
  }
}

综上，假设我们的任务命名为 release，就可以用 act -j release-assests 进行测试了：

$ act -j release-assests
[Build Release/release linux/amd64-3] 🧪  Matrix: map[goarch:arm64 goos:linux]
[Build Release/release linux/amd64-2] 🧪  Matrix: map[goarch:amd64 goos:darwin]
[Build Release/release linux/amd64-2] 🚀  Start image=catthehacker/ubuntu:act-latest
...
[Build Release/release linux/amd64-4] ⭐  Run Packaging...
[Build Release/release linux/amd64-4]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /Users/dustise/Dropbox/Synced/lab/karmada/source/workflow/3] user=
[Build Release/release linux/amd64-1]   ✅  Success - Packaging...
[Build Release/release linux/amd64-4]   ✅  Success - Packaging...

本地运行通过后，可以 Push 代码，创建 Release 来测试上传结果。

附录

Github Action Reference：https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions