走进GitHub Actions

关于

使用GitHub Actions，你可以在GitHub代码仓库中直接创建自定义的CI/CD工作流程！

特性

GitHub Actions借助世界一流的CI / CD，可轻松实现所有软件工作流程的自动化。直接从GitHub构建，测试和部署代码。使代码审查，分支机构管理和问题分类工作按你想要的方式进行。

• 在任意的GitHub事件上运行工作流程
• 托管运行器支持大多数的操作系统，包括Linux、macOS、Windows、ARM、containers
• 支持矩阵式构建
• 支持任意的开发语言
• 实时日志
• 内嵌的密钥存储
• 多容器测试
• 社区推动的工作流程

总览

如下图所示，GitHub Actions是事件驱动的，这意味着可以在发生指定事件后运行一系列命令。

该图演示了如何使用GitHub Actions自动运行软件的测试脚本。事件自动触发包含作业（Job）的工作流程(Workfolw)。然后，作业（Job）将使用步骤（Steps）来控制操作（Actions）的运行顺序。这些操作（Actions）是软件测试自动化的命令。

组件

下图展示了多个GitHub Actions组件协同运行作业（Job）。

• 工作流程（Workflows）

  • 工作流程是添加到代码仓库中(.github/workflow/{youworkfolw}.yaml）的自动化过程
  • 工作流程由一个或者多个作业（Job）组成
  • 可由事件或者调度器触发
  • 该工作流程可用于GitHub上的构建、测试、发布或者部署

• 事件（Events）

  • 事件是触发工作流程的特定活动，例如推送、拉去、创建问题等
  • 除GitHub内部的事件外，还可以使用Webhook在外部事件发生时，触发工作流程

• 作业（Jobs）

  • 作业是在同一个运行器上执行的一组步骤。
  • 默认情况下，具有多个作业的工作流将并行的执行这些作业

• 步骤（Steps）

  • 步骤是可以运行操作（Actions）的单个任务。
  • 作业中的每个步骤都在同一运行器上执行，从而使该作业中的操作可以彼此共享数据。

• 操作（Actions）

  • 操作是一些独立的命令，用来组合成步骤，进一步创建作业。
  • 操作是工作流程中最小的可移植构建模块。

• 运行器（Runners）

  • 运行器是GitHub Actions已安装的运行服务器
  • 可以使用GitHub托管的运行器，也可以使用自己托管的运行器
  • 运行器监听可用的作业，每次运行一个作业，并将进度、日志、结果反馈给GitHub
  • 对于GitHub托管的运行器，工作流中的每个作业都在新的虚拟环境中运行

实战

GitHub Actions使用YAML语法定义事件，作业和步骤。这些YAML文件存储在代码存储库中的.github / workflows目录中。

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
      - run: npm install -g bats
      - run: bats -v

1. 在代码仓库中创建.github/workflows目录结构来存放工作流程文件
2. 创建新的YAML文件命名为learn-github-actions.yml，并添加上述代码
3. 提交更改并推送至GitHub代码库

现在，工作流程已经安装在代码库中了，并且每次改动的提交都会自动运行。

解读

• name: learn-github-actions # 显示在Github Actions标签上的工作流的名称，可选
• on: [push] # 定义自动触发工作流程的事件
• jobs: # 当前工作流文件中所有作业的分组
• check-bats-version: # 工作组中的某个作业名称
• runs-on: ubuntu-latest # 当前作业在Ubuntu的环境中运行
• steps: # 作业check-bats-version中运行的所有的步骤
• • uses: actions/checkout@v2 # uses关键字告诉job去检索社区中命名为‘actions/checkout@v2’的操作，然后checkout代码并下载至运行器环境中。
• • uses: actions/setup-node@v1 # 这个操作在运行器环境上安装node
• • run: npm install -g bats # run关键字告诉job在运行器中执行一个命令
• • run: bats -v # 运行bats命令

整个工作流程及步骤如下图所示，

进阶

从切身的需求出发：混合部署

随着云原生架构下微服务的发展，除了传统的CI/CD的功能外，混合部署的需求也得到越来越多的重视。

为应对不同客户的部署需求，我们需要同时发布多种形式的资产，比如，

• 用于本地编译构建的源码
• 裸机环境下可以直接部署的Artifacts
• VM环境下可以容器化部署的Docker Image
• Kubernetes环境下的Helm Chart

如果通过一个版本tag或者修改下chart.yaml中的版本，就可以轻松的发布多种资产，这对提高工作的效率是有着莫大的帮助。

同时，在微服务架构下，也大大的降低了我们工程管理的成本和代价。

接下来让我们以Java工程为例，看下GitHub Actions是如何做到的呢？

• 构建与测试

      - name: Build with Maven
        run: mvn -B clean package --file pom.xml
      - name: maven verify
        run: mvn -B clean verify -Pintegration-test

• 发布Artifcacts

    - name: publish artifacts on github packages
      run: mvn -B clean deploy -DskipTests

• 上传Artifacts

      - run: mvn clean -B package --file pom.xml -DskipTests
      - run: mkdir staging && cp target/*.jar staging
      - uses: actions/upload-artifact@v1
        with:
          name: Package
          path: staging

• 发布源码

        - name: create release
          id: create_release
          uses: actions/create-release@v1
      

• 打包与镜像发布

    - name: Login to Docker Hub
      run: docker login -u ${{secrets.DOCKER_USER}} -p ${{secrets.DOCKER_PASS}}
    - name: build docker image
      run: docker build -t $REPO:latest -t $REPO:${GITHUB_SHA::8} .
    - name: publish docker image
      run: docker push $REPO 

• 发布Chart

     - name: Run chart-releaser
       uses: helm/chart-releaser-action@v1.0.0

经过上述几个工作流程的自动化任务，我们实现了多种资产的自动化发布。

Artifacts的发布展示：

Helm Chart的发布展示：

Docker Image发布展示：

详细的工作流程配置可参考Demo链接：github.com/MingningSha…

总结

GitHub Actions依托强大的GitHub，发展也是日新月异的。同时，也传承了GitHub开源的精神，吸引了众多的社区纷纷推出了自己的actions。也正是得益于活跃社区推出的各式各样的开箱即用actions，让使用GitHub Actions更加简单、灵活，功能更加的丰富。二者才能相得益彰，共同进步。当然，我们也可以自定义自己的actions，发布自己的actions到社区，贡献社区。如开篇所言，纵使高手林立，GitHub Actions已经闯出了自己的一片天地。GitHub环境下，GitHub Actions实为最佳之选！

由于篇幅有限，不能完全展开的讲解GitHub Actions，后续将会持续更新。