本文转载自微信公众号「老王Plus」，作者老王Plus的老王。转载本文请联系老王Plus公众号。
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：
- name: Sample Build
- on:
- push:
- branches:
- - main
- jobs:
- build:
- runs-on: ubuntu-latest
- 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
三、运行 Action
配置完成，下面就是运行了。
运行是在 Github 上面，当然先要提交代码了。提交到 Github，Action 就会按照我们设定的方式运行了。
本文的代码在：https://github.com/humornif/GithubActionSample
