我们一起Github Action 入门

Github Action，是 Github 推出的一个持续集成服务。

这个持续集成，有很多操作，例如：抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。就我自己而言，用的最多的是自动生成 Nuget 包并自动发布到 Nuget。这样，我可以只关心代码本身，代码完成后，Push 到仓库，后面就由 Action 去自动完成了。

这篇文章，我会从零开始，介绍一下 Action 的创建和使用。

一、在 Dotnet 工程中加入一个 Github Action

我们在 Github 上创建一个简单的 Dotnet 应用。看一下目录结构：

% tree -a .
.
├── .gitignore
├── GithubActionSample.sln
├── README.md
├── src
│ ├── GithubActionSample.csproj
│ └── Program.cs
└── tests

初始基本就是这么个样子。通常我会加入几个文件：README.md，用来写个说明;.gitignore，这个是提交时，定义跳过某些文件的定义，比方 bin、obj 下面的文件，是不需要提交上去的;tests 目录，里面是测试代码。当然，这儿我就省了。

Github Action 需要放在一个固定位置 - 在 Git 仓库的根目录中。

我们创建一个 .github 的目录，并在里面创建一个 workflows 的子目录。这就是我们要创建 Action 的目录了。注意，这个目录名称和结构不能改变。Github 会在这个位置查找工作流配置。

下面，我们在这个位置创建一个 Action 的定义。Action 要求是 YAML 文件。关于这个文件的格式，后面会讲到。

这个目录下，可以创建多个 YAML 文件，对应多个工作流的配置，每个工作流配置，对应不同的自动化需求。

我们先创建一个 Action，用来自动编译代码，文件名叫 Build.yml。完成后，看一下目录结构：

% tree -a .
.
├── .github
│ └── workflows
│ └── Build.yml
├── .gitignore
├── GithubActionSample.sln
├── README.md
├── src
│ ├── GithubActionSample.csproj
│ └── Program.cs
└── tests

这就是一个 Action 了。

下面，我们来一步步完成这个 Action 的配置。

二、完成 Action 配置

完成 Action 配置，其实就是完成上面这个 Build.yml 文件的内容。

1. 指定 Action 名称

先说明一下，按照 Github 的说明，这个名称不是必须的。不过通常来说，我会习惯加个名称。根据文件名判断作用，不是个好习惯。

格式很简单：

name: Sample build

2. 配置触发器

触发器，是用来定义这个 Action 在什么情况下被运行。

通常来说，会有几种选择：

单个事件，比方提交代码 Push 的时候，写法是：

on: push

多个事件，比方 Push 和 Pull Request 的时候，写法是：

on: [push, pull_request]

有时候，我们还需要增加更多的条件，比方 Push 和 Pull Request 到主分支的时候：

on:
push:
branches:
- main
pull_request:
branches:
- main

还有一个非常有用的触发器，就是定时器。比方我们要在特定的时间，或特定的周期下运行这个 Action，就可以用定时器。

定时器的写法是：

on:
schedule:
- cron: '5 * * * *'

这个定时器，采用的是 Linux 下 Cron 的定时器写法。具体的写法和含义，可以去查一下 Cron 的规则。

除此之外，还有一些更高级的用法，例如根据一个 Action 的结果，来触发另一个 Action 的执行。类似于这样的，可以去 Github 的文档中详细了解，这里是传送门。上面介绍的三种方式，在大多数情况下够用了。

在我们今天的例子中，我们希望在提交后触发编译。所以，我们采用第一种：

on:
push:
branches:
- main

触发器定义完了，下面该定义做什么了。在 Action 中，称为任务 Jobs。

3. 定义任务 Jobs

在规则中，一个触发器，可能对应多个任务，每个任务都需要有一个ID，和一个名称。

jobs:
first_job:
name: First job
second_job:
name: Second job

上面的例子，first_job 是ID，要求是一个词，可以使用下划线。而下面 First job 是名称。跟 Action 的名称一样，可以省略不写。

对于一个任务，下面又需要配置运行环境和步骤。

运行环境，指得是 Action 需要运行的外部操作系统，说白了，是 Github 给提供的虚拟机。当然，我们自己建立 VM 来运行也是可以的，不过通常就使用 Github 托管的VM了。有三种选择：Windows、Ubuntu Linux、macOS。

运行环境，用 runs-on 来标出：

jobs:
first_job:
name: First job
runs-on: windows

步骤，是定义做这件事需要几个步骤。每个步骤需要单独列出。Action 执行时，会按这个步骤一行一行执行。

直接看例子：

steps:
- uses: actions/checkout@v2
- name: Setup .NET SDK
uses: actions/setup-dotnet@v1
with:
dotnet-version: 5.0.x
- name: Restore
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore

这是一个简单的步骤例子。

第一步，用了 actions/checkout@v2，这是 GitHub Action 的公共操作，用来签出代码。

第二步，创建编译环境。在 runs-on 给出的 VM 是空的，需要我们自己建立环境。不过不需要像重新安装一个环境那样做。Github 给出了固定的环境创建方法。在这里，我们使用了 actions/setup-dotnet@v1 在环境里配置 Dotnet SDK，并定义了 SDK 的版本是 5.0 。

后面两个步骤，需要在环境中运行命令，所以使用了 run 关键字。这两个步骤，其实就是我们在命令行下生成并编译代码的两个命令。

最后，看一下完整的 Build.yml：