GitHub Action （一）

GitHub Actions

是一个由事件驱动的自动化平台，通过设置触发条件，在某些事件发生时自动运行指定的操作。换句话讲，GitHub Actions不仅允许开发人员在平台上托管代码，还可以操作它。通过GitHub Actions，我们能够自动化一个跨团队、手动且容易出错的流程。可以使每个团队能够独立运作，有助于提高生产力。

GitHub Actions的一个常见实用场景就是进行自动化的持续集成和部署。持续集成由很多操作组成，比如拉取代码、推送代码、运行测试，发布到第三方服务等等。

在这个过程中GitHub把开发者可以对代码执行的操作包装成了一个个功能模块，就叫action。开发者可以将多个actions组合成一个workflow工作流程。

例如，当指定发生拉取或推送操作时，触发GitHub CI服务器。执行由一个或多个actions组合到一起的workflow工作流程。

在GitHub Actions中，通过workflow工作流程指定需要运行的action，以及执行它们的触发器条件。workflow定义在当前操作的git仓库中的.github/workflows目录中，可以定义一个或多个workflow。workflow文件必须使用YAML语法，必须以.yml或.yaml作为文件扩展名。

每个action都是一个独立的功能，存放到指定的Actions仓库中。意味着如果你需要某功能，不必自己写，可以直接引用他人写好的action。Github自己维护了一个marketplace。还有一个awesome actions，也可以找到一些好用的actions。

要引用一个action，可使用userName/repoName的引用action。比如，actions/checkout就表示引用官方actions仓库的中的github.com/actions/checkout这个仓库，作用是checkout当前的使用的GitHub托管的服务器，以便workflow可以访问它。

actions/checkout@25a956c # 指向一个 commit
actions/checkout@v1    # 指向一个标签
actions/checkout@main  # 指向一个分支

如果，要访问使用非官方提供的action，通过userName/repoName：

lukka/run-vcpkg@v6
lukka/run-cmake@v3

接下来，我们来实际分析一个workflow。

Kingfisher

在Kingfisher的.github/workflows目录中有一个build.yaml。专门用来通过fastlane的scan或者gym来进行编译和测试示例工程的。

# 1
name: build

# 2
on: [push, pull_request]

# 3
jobs:
  run-test:
    # 4
    runs-on: macOS-latest
    # 5
    strategy:
      matrix:
        destination: [
          'macOS', 
          'iOS Simulator,name=iPhone 8', 
          'tvOS Simulator,name=Apple TV', 
          'watchOS Simulator,name=Apple Watch Series 5 - 40mm'
        ]
        swift-version: [5.0]
    # 6    
    steps:
      # 7
      - uses: actions/checkout@v1
      - uses: actions/cache@v1 # 8
        id: bundler-cache # 9
        with: # 10
          path: vendor/bundle 
          key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }} 
          restore-keys: |
            ${{ runner.os }}-gems-   
      # 11     
      - name: Bundle setup
        run: bundle config path vendor/bundle 
    
      - name: Bundle install
        if: steps.bundler-cache.outputs.cache-hit != 'true' # 12
        run: bundle install --jobs 4 --retry 3
      - name: Run tests
        env: # 13
          DESTINATION: platform=${{ matrix.destination }}
          SWIFT_VERSION: ${{ matrix.swift-version }}
        run: bundle exec fastlane test_ci # 14

我们一个步骤一个步骤的来分析：

1. name：workflow的名称。当前的workflow名称被设置为build；

2. on必填。用来指定触发条件，触发条件被触发开始执行。当前的workflow被触发的条件有两个：push和pull_request。当发生push或pull操作时，触发该workflow；

3. jobs指定当前的workflow在被触发时可以运行的一项或多项jobs；

4. jobs.<job_id>.runs-on必填。指定要运行job的服务器类型。当前的workflow指定的服务器器为GitHub提供的macOS-latest；

5. jobs.<job_id>.strategy.matrix：构建矩阵，当前workflow中有两个key：

• destination指明bundle的缓存key、fastlane的产物类型；
• swift-version用的Swift版本。

6. steps指明当前job包含的具体步骤：

1. 第一个步是运行github提供的checkout action。将当前仓库checkout到当前的服务器；
2. 第二步，配置fastlane需要的ruby环境。使用官方提供actions/cache来缓存ruby gems。在这篇Ruby Gems缓存会详细介绍；
3. jobs.<job_id>.steps[*].id，当前step的唯一标识。用于在上下文环境中引用该step；
4. jobs.<job_id>.steps[*].with：指明当前action序言的输入参数，使用map。每个输入参数都是一个键/值对。如果当前输入的不是action需要的输入参数，那么这些参数将被设置为环境变量。该变量的会自动加上前缀INPUT_，并转换为大写；
5. 当我们不需要action时，可以使用name表明步骤的名称和run指明步骤执行时构建服务器将运行的命令，来自定义一个step；
6. jobs.<job_id>.steps[*].if，通过if: 表达式，判断当前是否满足step运行需要的信息；
7. jobs.<job_id>.steps[*].env，用于设置当前step的环境变量；
8. 最后，通过fastlane执行在fastlane目录中的Fastfile定义的test_ci lane。