我们一起Github Action 入门

本文转载自微信公众号「老王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