GitHub Actions进阶课程

# 1. GitHub Actions基础与概念

GitHub Actions是GitHub平台的一项功能，它允许开发者自动化软件开发工作流程，使得从代码提交到部署的每一步都可以实现自动化处理。其核心是基于Actions的自动化工作流程，通过定义一系列的Events（事件）、Jobs（作业）、Steps（步骤）来完成。开发者可以通过编写YAML格式的配置文件来定义和配置工作流程，使其能够响应各种事件，如代码推送、拉取请求等，并执行一系列任务，如测试代码、发布应用程序等。GitHub Actions不仅限于GitHub内部使用，还可以集成第三方服务和工具，让自动化工作流更加灵活和强大。

# 2. GitHub Actions工作流程详解

## 2.1 触发工作流程的事件

### 2.1.1 事件类型与触发时机
GitHub Actions 的工作流程通常由事件（events）触发，这些事件代表了在仓库中发生的具体操作，比如代码被推送（push）、合并请求（pull requests）的创建或合并（merge）、问题或讨论的开启（issues or discussions），或者由特定的API调用触发（repository dispatch）。

事件类型涵盖了代码的变更、项目的管理活动、项目的网页浏览记录等。工作流程的触发时机需要根据事件类型来确定，例如：
- 当你进行push操作时，可以立即触发工作流程，以确保代码合并前的自动化测试。
- 在pull request创建后，可以在某个分支上自动执行工作流程，来提供代码审查的信息。
- 在Webhook事件触发下，例如GitHub的release事件，可以在版本发布时自动运行工作流程，以打包和部署应用。

### 2.1.2 事件的过滤和限制
过滤事件可以限制工作流程在特定条件下执行。在工作流的配置文件（workflow.yml）中，你可以指定特定事件的分支、路径或标签，仅当事件发生在这些条件下时，工作流程才会运行。

事件的过滤通常通过`on`关键字来指定，可以在其后定义一个或多个过滤条件，如：

on:
  push:
    branches:
      - main
      - 'releases/**'
  pull_request:
    paths:
      - '**/my_new_feature/**'

在这个示例中，工作流程会在主分支`main`或任何`releases/`的分支上发生push事件时运行。同时，如果在`my_new_feature`目录下有pull request操作时，也将触发工作流程。

## 2.2 工作流程的构成要素

### 2.2.1 Job的定义和依赖关系
工作流程是由一个或多个job构成的。每个job是工作流程中的一个执行单元，通常包括运行一系列步骤（steps）的指令。job可以相互独立，也可以定义依赖关系。比如，你可能希望在一个依赖于另一个job成功完成之后才开始执行。

在定义job时，你可以指定运行环境（如操作系统）、运行步骤、依赖关系以及并行运行等属性。依赖关系通过`needs`关键字来定义，指明了当前job依赖于其他哪些job的完成。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build with Docker
        run: docker build -t my-app .
  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to server
        run: my-deploy script.sh

上述代码中定义了两个job：`build` 和 `deploy`。`deploy` job 依赖于 `build` job 的成功完成，即`deploy`在`build`成功后才会运行。

### 2.2.2 Step的类型与配置
在GitHub Actions中，一个job由一系列的step构成，每个step可以是一个运行命令的任务，也可以是一个调用一个Action的动作。Step是工作流程中的最小操作单元。

Step的类型主要包括以下几种：
- 使用`run`指令来运行shell命令。
- 使用`uses`指令来调用一个预先定义好的Action。
- 使用`with`关键字传递参数给Action。
- 使用`name`关键字为step命名，以便在日志中容易识别。

- name: Checkout code
  uses: actions/checkout@v2

- name: Setup Node.js
  uses: actions/setup-node@v1
  with:
    node-version: '12'

- name: Install Dependencies
  run: npm install

- name: Run Tests
  run: npm run test

上述代码展示了在Node.js项目中，如何通过step来安装依赖并运行测试。

### 2.2.3 Action的使用和定制
Action是GitHub Actions的核心组件，它是一个可复用的代码块，用于执行一个或多个任务。GitHub市场提供了许多预定义的Action，但你也可以创建自己的自定义Action来满足特定需求。

使用Action时，可以通过`uses`关键字指定Action的来源，包括：
- GitHub仓库中的Action。
- Docker Hub中的容器。
- 自己构建的容器镜像。

- name: Run Custom Action
  uses: ./.github/actions/my-custom-action
  with:
    param1: value1
    param2: value2

在这个例子中，我们调用了本地仓库中的自定义Action，并传递了两个参数。

定制Action通常意味着创建自己的Docker容器或者JavaScript文件（例如`action.yml`和`index.js`），这些文件定义了Action的元数据和运行逻辑。自定义Action使你能够封装复杂的逻辑，并在多个工作流中重用它们。

## 2.3 环境变量与上下文

### 2.3.1 环境变量的设置和作用域
环境变量在工作流程中被广泛使用，它们可以设置在多个级别，包括仓库级别、工作流程级别、job级别、step级别。环境变量的作用域决定了它们在工作流程中哪里可以被访问到。

- **仓库级别**：在仓库的设置中定义的环境变量，对仓库中所有工作流程可见。
- **工作流程级别**：在`workflow.yml`文件中定义的环境变量，对当前工作流程可见。
- **Job级别**：在job中定义的环境变量，仅对当前job可见。
- **Step级别**：在step中定义的环境变量，仅对该step可见。

使用`env`关键字来定义环境变量，例如：

jobs:
  show-env:
    runs-on: ubuntu-latest
    env:
      PROJECT: MyProject
    steps:
      - name: Show environment variable
        run: echo $PROJECT # 输出 "MyProject"

在这个例子中，`PROJECT`环境变量被设置在job级别，因此可以在该job的所有step中访问。

### 2.3.2 上下文信息的提取与应用
上下文信息在GitHub Actions中提供了对仓库、工作流程、事件触发等信息的访问。上下文可以用于动态获取信息，以便在工作流程中使用。

上下文通常在工作流程文件中以`${{ context.name }}`的形式使用。一些常用的上下文包括：
- `github`: 包含与触发工作流程的事件相关的详细信息。
- `secrets`: 包含仓库或组织中的敏感信息。
- `job`: 包含当前job的信息。
- `steps`: 包含前一步骤输出的信息。

jobs:
  print-context:
    runs-on: ubuntu-latest
    steps:
      - name: Dump GitHub context