研发效能领域洞察 | GitHub又一杀手级特性：GitHub Actions

研发效能领域洞察系列

一直以来，GitLab的CI/CD功能是相较GitHub的差异性特性优势，作为开源世界最大的代码服务平台，GitHub自然不甘示弱，在GitHub Apps的基础上补充了更为轻量级的工作流编排与插件体系，经过近一年试运行，终于在2019年8月8日正式宣布GitHub Actions支持CI/CD，与代码活动高度集成、开发者视角的信息架构整合，再加上开放低成本的插件接入体系，可谓是集GitLab CI与Jenkins的优势于一身。 本文由蚂蚁金服研发效能专家带你了解GitHub Actions的特性和亮点。

:rocket:我们招聘了！ 招聘详情见文末！！！

01

前言

GitHub和GitLab是世界上最流行的两大代码服务平台，两者目标受众有所区别。

GitHub在开源世界拥有绝对优势， 绝大部分的知名开源项目工作在GitHub上，拥有庞大的用户群，推崇开源文化与social coding，被国内朋友戏称为“全世界最大的同性交友社区”。然而在2018年10月21日那场让全世界围观的MySQL数据库事故（Incident Report）之后，许多用户将托管在GitHub上的代码库与GitLab做了数据同步，在微软以75亿美金收购GitHub之后，更有意气用事者从GitHub迁移至GitLab。

而在企业领域，GitHub Enterprise收费高昂， GitLab则以开源优势更胜一筹 ，规模较小的公司使用CE版即可满足需求，大公司则有机会进行二次开发。与许多国内同行一样， 蚂蚁金服的代码服务亦是基于GitLab原生能力的定制增强版，实现了高可用、高并发的设计，以支撑蚂蚁内外部万级用户的研发场景。

一直以来，GitLab从产品功能上相较GitHub的特色优势是基于代码事件与信息架构的持续集成功能，开发者视角的设计理念使得体验非常自然方便，在此基础上发展出来的GitLab Auto DevOps更是从CI领域拓展到了CD领域。

与之对标的GitHub解决方案则是与第三方CI/CD系统进行集成，例如CI/CD平台Travis CI与Circle CI，覆盖率平台Codecov等。这样做的劣势非常明显，对工作流无编排能力，软件工程领域的原子能力游离于GitHub体系之外不利于整合发展。

2019年8月8日， GitHub正式发布GitHub Actions，对公开项目免费，被业界评价为GitHub的杀手级特性。

02

GitHub Actions是事件编排与执行系统

官方定义GitHub是一个因果系统（cause and effect），基于任何事件编排任何工作流，管理执行，提供反馈，确保安全。

GitHub并没有将领域模型限制在CI/CD或DevOps领域，为将来的可能性留足了空间，例如是否有机会形成code driven的算法训练工作流（本质也是流水线编排），这是高明之处。

03

GitHub Actions与GitHub Apps的区别

GitHub的Marketplace提供Actions和Apps。

GitHub Apps是持续提供服务的应用，与GitHub APIs集成，需要安装部署，通常是一些第三方的产品。而GitHub Actions则不需要部署，直接在VM或container里运行，通常是一些工具类的小功能。

与此类似，我们蚂蚁ACI的插件体系也包含RESTful方式对接的第三方系统，对标GitHub Actions的轻量级utils类插件接入方式正在建设中，将极大降低开发成本。

核心模型对比

GitHub Actions的模型如下：

• workflow： 一个可配置的自动化过程，由一个或多个job组成，可被计划，可被事件触发。

• job： 由若干step组成，每个job独立的运行于同一个虚拟环境中，job之间可设置依赖，以实现串行执行或并行执行。

• step： 由一组任务组成，被job所执行。一个job内的step运行于同一个环境中，因此可以通过文件系统share信息。step可以执行命令或者action。

• action： workflow中的最小单元，若干独立的任务，可组合成step。

name: Greet Everyone

# This workflow is triggered on pushes to the repository.

on: [push]

jobs:

build:

# Job name is Greeting

name: Greeting

# This job runs on Linux

runs-on: ubuntu-latest

steps:

# This step uses GitHub's hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action

- name: Hello world

uses: actions/hello-world-javascript-action@v1

with:

who-to-greet: 'Mona the Octocat'

id: hello

# This step prints an output (time) from the previous step's action.

- name: Echo the greeting's time

run: echo 'The time was ${{ steps.hello.outputs.time }}.'

GitLab CI的模型如下：

pipeline

|__ stages

|__  jobs 

Github Actions

GitLab CI

Comments

workflow

pipeline

一致

无对应元素

stage

GitHub Actions没有stage元素，通过job的needs语法来定义执行顺序，形成DAG树状拓扑；而Jenkins和GitLab CI有stage元素，需要将一个stage下所有job执行完后才能继续执行后续stage，在一些情况下整体执行时间较长。

job

job

GitLab CI的最小执行单元是job，颗粒度较粗。

step

scripts

GitHub Actions的 step可以执行命令或者使用action两种形式，可结构化的组装多个原子步骤。而GitLab CI的执行内容定义在job下的scripts中，只能执行命令。

action（插件接入层）

无对应元素

无插件能力

功能特性对比

GitHub Actions具备以下基本功能：

• 环境变量定义与引用

• 加密变量

• GITHUB_TOKEN

• 缓存

• 产物持久化

• 事件触发

• 上下文

• 表达式

除此之外，以下特性与GitLab有较大区别：

GitHub Actions

GitLab CI

插件体系

有，社区贡献，目前有1325个actions

无，测试安全等核心能力集成开源项目，提供开箱即用套件

预定义模版

有

无

运行环境

GitHub提供的runner包括Azure VM上的windows环境和Ubuntu环境，Macstadium上的macOS环境，支持自定义

提供基于 Google Cloud Platform的 自动自动扩缩容的shared runner，支持自定义

环境管理

无

有

03

GitHub Actionsd的亮点功能

配置代码化

  文件

与其他主流CI系统一样，GitHub工作流的配置是代码化的，因此非常利用软件开发实践的创建、分享、复用和演化。

我们蚂蚁的自定义流水线产品AntCode-ACI也是支持配置代码化的，也支持内置模版和第三方系统编排流水线。

Action配置是位于代码库根目录下.github/workflows目录的一组文件，将workflow与action的配置分开，类似Ansible的playbook和module，可实现复杂的组织形式。而GitLab CI则简单得多，使用include语法对yml进行组装，结构性差一些。

|-- hello-world (repository)

|   |__ .github

|       └── workflows

|           └── my-first-workflow.yml

|       └── actions

|           |__ hello-world-action

|               └── action.yml

  命名

GitHub Actions的YML语法及上下文命名的结构性一致性较好，例如触发条件表达为 on.<push|pull_request>.<branches|tags>，产出物表达为steps.<step id>.outputs。

  可编程

GitHub Actions 支持运算符、表达式和一些内置函数 ，灵活性就比GitLab-CI等强大多了， 跟Ansible语法比较类似，将来支持Jinja模版也未可知 。Jenkinsfile除声明式语法之外还可以引入groovy语法甚至Java语法，可编程性也非常强，但是结构化欠缺。目前在蚂蚁内部还未出现需要强编程的场景，将来如果要发展这方面的特性，参考GitHub Actions为宜。

友好的创建方式

同样是配置代码化，GitHub Actions的workflow创建方式友好程度好很多，online editor支持对workflow配置文件进行在线编辑、提交，可按类别浏览预定义模版，方便的展示事例和帮助文档，这在ACI产品化建设上有参考意义。

丰富的事件驱动，支持自定义

GitHub Actions支持的触发事件非常丰富完善，有三大类：

1.  Webhook events： GitHub的webhook本身非常丰富开放，通过这些webhook可触发workflow，可支持多个配置，这种方式涵盖了绝大部分的场景且内外保持一致，支持场景比GitLab CI多出几个数量级。

2. Scheduled events： cron语法的定时触发

3. External events： 使用GitHub API向代码库的一个叫repository_dispatch的webhook提交自定义的payload，则可以实现通过外部事件触发workflow的效果，这个方案使得内外部触发形式得到统一。相比通常通过API触发，差异性需求需要用户向产品维护者提需求来实现，自定义webhook方式灵活性更高。

插件体系

在GitHub Marketplace上，有178个apps，有1525个actions，生态布局已经非常丰富。

GitHub Actions插件的优势是开发和接入的门槛低，结构性好，易于分享。 相比GitHub Apps而言，无需提供基础设施，运行时由GitHub提供，适合实现utils、命令执行类等实时执行的轻量级原子任务，具有以下特性：

• 可与GitHub和第三方服务的APIs进行集成

• 可以独有，也可以公开分享

• 可以定义输入、输出、环境变量

GitHub Actions是对GitHub Apps的补充，两者各有特点：

GitHub Apps

• 运行在自己提供的基础设施上

• 持续运行，事件响应快

• 适合数据持久化

• 访问API没有延迟

GitHub Actions

• 提供CI/CD的自动化编排能力

• 不需要部署应用服务

• 可以直接在虚拟机或Docker容器里运行

• 可以用于访问代码库、部署和发布、代码格式化等命令行工具等

• 使用密钥简单，与第三方服务交互时不需要存储个人证书

04

如何定义

GitHub Actions的配置文件和执行程序可以放在任意的独立仓库中被别人引用，例如放在GitHub Actions group下的是官方提供的actions，awesome-actions下收集了很多社区维护的actions。这种松散的方式意味着定义一个actions没有任何门槛，这比Jenkins插件的开发发布简单很多，可见度高很多，也意味着没有中心化的组织来对具体插件的质量进行把关，actions的好与坏是依靠社区的方式自然浮现的。

定义GitHub Actions的方式是使用metadata描述文件action.yml来定义输入、输出和程序入口这三个核心元素。例如这个给PR打标签的actions：https://github.com/actions/labeler，目录结构如下：

--
|--src
    |--main.ts          # 执行程序
|--toolkit                # GitHub提供的JavaScrip SDK
|--action.yml            # action描述文件
|--README.yml
|--LICENSE
|-- 

在action.yml中定义以下元数据：

name: 'Pull Request Labeler'
description: 'Label pull requests by files altered'
author: 'GitHub'
inputs: 
  repo-token:
    description: 'The GITHUB_TOKEN secret'
  configuration-path:
    description: 'The path for the label configurations'
    default: '.github/labeler.yml'
runs:
  using: 'node12'
  main: 'lib/main.js'         # 程序入口

在workflow中使用这个action：

name: "Pull Request Labeler"
on:
- pull_request

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/labeler@v2
      with:
        repo-token: "${{ secrets.GITHUB_TOKEN }}"

const core = require('@actions/core');
const github = require('@actions/github');

try {
  // `who-to-greet` input defined in action metadata file
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = (new Date()).toTimeString();
  core.setOutput("time", time);
  // Get the JSON webhook payload for the event that triggered the workflow
  const payload = JSON.stringify(github.context.payload, undefined, 2)
  console.log(`The event payload: ${payload}`);
} catch (error) {
  core.setFailed(error.message);
}

长按识别二维码关注我们

P.S.

蚂蚁金服研发效能团队招募进行中， 解决方案架构师、技术运营、数据研发专家、技术专家、技术支持专家、 产品专家、测试平台高级开发工程师、代码分析技术专家 等众多岗位持续开放，让我们共同开赴DevMind/DevOps/DevServices三大战场，助力内部及外部伙伴研发效能的持续提升:rocket::rocket::rocket:

如果你对任何岗位感兴趣，请留下联系方式，或者发简历到： [email protected]

技术同学请附上你的GitHub/GitLab个人地址哦~

▼  点击“阅读原文”获取更多职位详情