GitHub之GitHub Actions的项目自动化持续集成和部署

一、基本概念

• GitHub Actions 是一个由事件驱动的自动化平台，通过设置触发条件，在某些事件发生时自动运行指定的操作。换言之，GitHub Actions 不仅允许开发人员在平台上托管代码，还可以操作它，通过 GitHub Actions，能够自动化一个跨团队、手动且容易出错的流程，可以使每个团队能够独立运作，有助于提高生产力。
• GitHub Actions 可以直接在 GitHub 库中创建自定义的工作流，工作流指的就是自动化的流程，比如构建、测试、打包、发布、部署等等，也就是可以直接进行 CI（持续集成）和 CD（持续部署）。持续集成由很多操作组成，比如拉取代码、推送代码、运行测试，发布到第三方服务等等。
• 在这个过程中，GitHub 把开发者可以对代码执行的操作包装成了一个个功能模块，就叫 action，开发者可以将多个 actions 组合成一个 workflow 工作流程：
• • workflow: 一个 workflow 工作流就是一个完整的过程，每个 workflow 包含一组 jobs 任务。
• • job : jobs 任务包含一个或多个 job ，每个 job 包含一系列的 steps 步骤。
• • step : 每个 step 步骤可以执行指令或者使用一个 action 动作。
• • action : 每个 action 动作就是一个通用的基本单元。

二、配置 workflow

① workflow 的配置

• GitHub Actions 的配置文件叫做 workflow 文件，存放在代码仓库的 .github/workflows 目录。
• workflow 文件采用 YAML 格式，文件名可以任意取，但是后缀名统一为 .yml，比如 foo.yml。一个库可以有多个 workflow 文件。GitHub 只要发现 .github/workflows 目录里面有 .yml 文件，就会自动运行该文件。
• 当指定发生拉取或推送操作时，触发 GitHub CI 服务器，执行由一个或多个 actions 组合到一起的 workflow 工作流程，如下所示：

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

	name:GreetEveryone
	# This workflow is triggered on pushes to the repository.
	on: [push]
	jobs:
	your_job_id:
	# Job name is Greeting
	name: Greeting
	# This job runs on Linux
	runs-on: ubuntu-latest
	steps:
	# This step uses GitHub's hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action
	- name: Hello world
	uses: actions/hello-world-javascript-action@v1
	with:
	who-to-greet: 'Mona the Octocat'
	id: hello
	# This step prints an output (time) from the previous step's action.
	- name: Echo the greeting's time
	run: echo 'The time was ${{ steps.hello.outputs.time }}.

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
 

• • 示例说明：
• • • 最外层的 name 指定了 workflow 的名称；
• • • on 声明了一旦发生了 push 操作就会触发这个 workflow；
• • • jobs 定义了任务集，其中可以有一个或多个 job 任务，示例中只有一个；
• • • runs-on 声明了运行的环境；
• • • steps 定义需要执行哪些步骤；
• • • 每个 step 可以定义自己的 name 和 id，通过 uses 可以声明使用一个具体的 action，通过 run 声明需要执行哪些指令；
• • • ${{}}可以使用上下文参数。
• • 上述示例可以抽象为：

	name: <workflow name>
	on: <events that trigger workflows>
	jobs:
	<job_id>:
	name: <job_name>
	runs-on: <runner>
	steps:
	- name: <step_name>
	uses: <action>
	with:
	<parameter_name>: <parameter_value>
	id: <step_id>
	- name: <step_name>
	run: <commands>

  

 

  
1
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
 

• 每个 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  # 指向一个分支

  

 

  
1
  
2
  
3
 

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

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

  

 

  
1
  
2
 

② workflow 的基本字段

• name
• • name 字段是 workflow 的名称，如果省略该字段，默认为当前 workflow 的文件名：

	name: GitHub Actions Demo

  

 

  
1
 

• on
• • on 字段指定触发 workflow 的条件，通常是某些事件。push 事件触发 workflow，如下所示：

	on: push

  

 

  
1
 

• • on 字段也可以是事件的数组。push 事件或 pull_request 事件都可以触发 workflow，如下：

	on: [push, pull_request]

  

 

  
1
 

• • 用来指定触发条件，触发条件被触发开始执行。可以提供单一触发条件 string、一组触发条件 array、不同事件类型 types 的一组条件 array 或 map，指明 workflow 的运行条件，或将 workflow 的执行限于特定文件、标记或分支更改。
• jobs.<job_id>.name
• • workflow 文件的主体是 jobs 字段，表示要执行的一项或多项任务。jobs 字段里面，需要写出每一项任务的 job_id，具体名称自定义。job_id 里面的 name 字段是任务的说明。
• • jobs 字段包含两项任务，job_id 分别是 my_first_job 和 my_second_job，如下所示：

	jobs:
	  my_first_job:
	    name: My first job
	  my_second_job:
	    name: My second job

  

 

  
1
  
2
  
3
  
4
  
5
 

• on.<push|pull_request>.<tags|branches>
• • 指定触发事件时，可以限定分支或标签，只有 master 分支发生 push 事件时，才会触发 workflow，如下所示：

	on:
	  push:
	    branches:    
	      - master

  

 

  
1
  
2
  
3
  
4
 

• jobs.<job_id>.needs
• • needs 字段指定当前任务的依赖关系，即运行顺序。如下所示，job1 必须先于 job2 完成，而 job3 等待 job1 和 job2 的完成才能运行。因此，这个 workflow 的运行顺序依次为：job1、job2、job3：

	jobs:
	  job1:
	  job2:
	    needs: job1
	  job3:
	    needs: [job1, job2]

  

 

  
1
  
2
  
3
  
4
  
5
  
6
 

• jobs.<job_id>.runs-on
• • runs-on 字段指定运行所需要的虚拟机环境，它是必填字段，目前可用的虚拟机如下：

	ubuntu-latest，ubuntu-18.04或ubuntu-16.04
	windows-latest，windows-2019或windows-2016
	macOS-latest或macOS-10.14

  

 

  
1
  
2
  
3
 

• • 指定虚拟机环境为 ubuntu-18.04：

	runs-on: ubuntu-18.04

  

 

  
1
 

• jobs.<job_id>.steps
• • steps 字段指定每个 Job 的运行步骤，可以包含一个或多个步骤。每个步骤都可以指定以下三个字段：

	jobs.<job_id>.steps.name：步骤名称
	jobs.<job_id>.steps.run：该步骤运行的命令或者 action
	jobs.<job_id>.steps.env：该步骤所需的环境变量

  

 

  
1
  
2
  
3
 

三、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
  
2
  
3
  
4
  
5
  
6
  
7
  
8
  
9
  
10
  
11
  
12
  
13
  
14
  
15
  
16
  
17
  
18
  
19
  
20
  
21
  
22
  
23
  
24
  
25
  
26
  
27
  
28
  
29
  
30
  
31
  
32
  
33
  
34
  
35
  
36
  
37
  
38
  
39
  
40
  
41
  
42
  
43
  
44
 

• 步骤分析：
• • name：workflow 的名称，当前的 workflow 名称被设置为 build；
• • on 必填，用来指定触发条件，触发条件被触发开始执行。当前的 workflow 被触发的条件有两个：push 和 pull_request，当发生 push 或 pull 操作时，触发该 workflow；
• • jobs 指定当前的 workflow 在被触发时可以运行的一项或多项 jobs；
• • jobs.<job_id>.runs-on 必填，指定要运行 job 的服务器类型。当前的 workflow 指定的服务器器为 GitHub 提供的 macOS-latest；
• • jobs.<job_id>.strategy.matrix：构建矩阵，当前 workflow 中有两个 key：
• • • destination 指明 bundle 的缓存 key、fastlane 的产物类型；
• • • swift-version 用的 Swift 版本。
• • steps 指明当前 job 包含的具体步骤：
• • • 第一个步是运行 github 提供的 checkout action，将当前仓库 checkout 到当前的服务器；
• • • 第二步，配置 fastlane 需要的 ruby 环境，使用官方提供 actions/cache 来缓存 ruby gems；
• • • jobs.<job_id>.steps[*].id，当前 step 的唯一标识，用于在上下文环境中引用该step；
• • • jobs.<job_id>.steps[*].with：指明当前 action 序言的输入参数，使用 map，每个输入参数都是一个键值对。如果当前输入的不是action 需要的输入参数，那么些参数将被设置为环境变量。该变量的会自动加上前缀 INPUT_，并转换为大写；
• • • 当我们不需要 action 时，可以使用 name 表明步骤的名称和 run 指明步骤执行时构建服务器将运行的命令，来自定义一个 step；
• • • jobs.<job_id>.steps[*].if，通过 if 表达式，判断当前是否满足 step 运行需要的信息；
• • • jobs.<job_id>.steps[*].env，用于设置当前 step 的环境变量；
• • • 最后，通过 fastlane 执行在 fastlane 目录中的 Fastfile 定义的 test_ci lane。

文章来源: blog.csdn.net，作者：Serendipity·y，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/Forever_wj/article/details/119645029