Github Action 入门

原创

霡霂

修改于 2020-06-16 14:24:12

1.1K0

修改于 2020-06-16 14:24:12

这篇文章是开源章节系列的一篇，讲解 Github Action，以及一些应用样例。

Github Action，是 GitHub 提供了一套 CI/CD 方案，本质就是在 GitHub 产生交互事件时（ Push，Tag,Issue……），触发一些预定的脚本，脚本中可以对代码进行单元测试，代码检查，静态编译等；并将报告输出到合适的地方（可以在PR中评论，直接在Diff中输出，或发送到分析面板），也可以基于一定的授权进行代码改写并提交到仓库。

CI/CD

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。 -- <CI/CD是什么？如何理解持续集成、持续交付和持续部署>

无论是开源项目还是内部项目，在项目的推进过程中，都会并行的进行特性研发；持续集成就是指将完成的某一特性尽快的完成测试和验证，以便尽快的合并到主干。

在提交代码后，自动的进行代码语法检查，风格检查，静态分析，以及单元测试和集成测试；以保证准备合入主干的代码是完成可用的；通常情况下，会在合并请求时进行集成检测，如果集成失败则禁止合并入主干，要求提交着进行修改。

在 Github Action 发布之前，大多数开源项目基于 TravisCI；当然，两个平台到目前也都各具特色，两者对开源项目都提供一定的免费资源；GitHub 在与 PR 或 Issue 的配合或其生态都有更丰富的扩展，TravisCI 则在不同开发语言和领域具有更好的应用场景，具体可与参见一些成熟的开源项目。

Github Action

启用

两种方法，一种是通过直接在仓库中添加配置文件，Github 会在对应的位置检查到文件后，进行解析，生成相关规则；二种是直接在页面上创建/编辑相关文件，会在编辑栏有相关 Action 的推荐，可直接添加到配置文件内。

可以看出，两种方式的本质均是通过仓库内的文件进行启用，Github 会在相关动作触发后检查是否存在相关配置文件，即 .github/workflows 目录下是否存在 *.yml 文件，并检查配置文件有效性。

配置

name: Go

# 动作触发的时机
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

# 触发后的动作
jobs:
  build:
    name: Build
	# 允许的系统环境，支持 linux,win,mac
    runs-on: ubuntu-latest
    steps:
	
	# 任务列表
    - name: Set up Go 1.x
	  # uses 代表引入了其他任务脚本，相当于引用公共脚本
      uses: actions/setup-go@v2
      with:
        go-version: ^1.13
      id: go

    - name: Check out code into the Go module directory
      uses: actions/checkout@v2

    - name: Build
	  # run 后写自己需要执行的脚本
      run: go build -v .

    - name: Test
      run: go test -v .

configuring-actions 可以获得更多关于配置文件的资料。

Workflows 对应着 .github/workflows 目录下的一个个文件，即在动作触发后的任务集；

steps 对应着，一个任务里的命令集，即执行的具体指令。

任务产出

Workflow 本质即一个 Docker 的运行时，在任务触发时，基于对应的 docker image 启动，并将 steps 对应的脚本填充执行脚本；所以，任务的产出可以多种多样，可以将编译的可执行文件上传至 Artifact；也可以将测试报告发往测试分析平台；亦或将仓库发布到注册中心(www.npmjs.com, https://pypi.org, https://packagist.org)，发布 Release 附件等。

Upload a Release Asset

在触发 tags 动作时，编译可执行文件，并上传到对应的 Release。

on:
  push:
    # Sequence of patterns matched against refs/tags
    tags:
    - 'v*' # Push events to matching v*, i.e. v1.0, v20.15.10

name: Upload Release Asset

jobs:
  build:
    name: Upload Release Asset
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

	  # 执行对应的编译脚本
      - name: Build project 
        run: |
          zip --junk-paths my-artifact README.md

	  # 创建 Release
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          prerelease: false
	  # 将编译得到的文件上传到上面创建的 Release
      - name: Upload Release Asset
        id: upload-release-asset 
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }} 
          asset_path: ./my-artifact.zip
          asset_name: my-artifact.zip
          asset_content_type: application/zip

发布代码到注册中心(www.npmjs.com, https://pypi.org, https://packagist.org)，和本地上传到注册中心类似，这里就不在举例。