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 Greetingname: Greeting# This job runs on Linuxruns-on: ubuntu-lateststeps:# This step uses GitHub's hello-world-javascript-action: https://github.com/actions/hello-world-javascript-action- name: Hello worlduses: actions/hello-world-javascript-action@v1with: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 timerun: echo 'The time was ${{ steps.hello.outputs.time }}.

- 示例说明：
- 最外层的 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>

每个 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 # 指向一个 commitactions/checkout@v1    # 指向一个标签actions/checkout@main  # 指向一个分支

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

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

② workflow 的基本字段

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

 name: GitHub Actions Demo

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

 on: push

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

 on: [push, pull_request]

- 用来指定触发条件，触发条件被触发开始执行。可以提供单一触发条件 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 jobmy_second_job:name: My second job

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

 on:push:branches:    - master

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

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

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

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

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

 runs-on: ubuntu-18.04

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

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

三、Kingfisher

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

 # 1name: build# 2on: [push, pull_request]# 3jobs:run-test:# 4runs-on: macOS-latest# 5strategy: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 # 8id: bundler-cache # 9with: # 10path: vendor/bundle key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }} restore-keys: |${{ runner.os }}-gems-   # 11     - name: Bundle setuprun: bundle config path vendor/bundle - name: Bundle installif: steps.bundler-cache.outputs.cache-hit != 'true' # 12run: bundle install --jobs 4 --retry 3- name: Run testsenv: # 13DESTINATION: platform=${{ matrix.destination }}SWIFT_VERSION: ${{ matrix.swift-version }}run: bundle exec fastlane test_ci # 14

步骤分析：
- 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。

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

使用Jenkins，GitHub和Docker的最先进的持续集成和部署管道
搭建舞台在过去的两年中,我一直在从事Node.js项目. 我们使用GitHub进行源管理,使用Jenkins进行持续集成. 我们还有一个基于Docker和Terraform的部署工具 . 在此期间, ...
jenkins+git+maven搭建项目自动化持续集成
2019独角兽企业重金招聘Python工程师标准>>> 1.概要说明为了开发人员和测试人员的解耦,让开发和测试流程更加便捷,所以采用jenkins+git+maven这套可持续性集 ...
.NET Core 从 Github到 Nuget 持续集成、部署
一.前言 Nuget 作为一个.NET研发人员,我想你都不会陌生,他为我们提供非常方便的程序包管理,不管是版本,还是包的依赖都能轻松应对,可以说是我们的好助手.而 Nuget 除了官方nuget.or ...
如何为Docker项目创建持续集成持续部署 (CI-CD)解决方案
目录目标发布Release 版本发布Beta版总结我不是Docker高手,但我知道它非常有用,我喜欢在一些项目中时不时地使用它.我喜欢的另一件事是DevOps和自动化,在我拥有的一个项目中, ...
CI/CD——构建企业级Docker+Jenkins+Git+Harbor流水线自动化持续集成持续发布平台
构建企业级Docker+Jenkins+Git+Harbor流水线自动化持续集成持续发布平台 CI/CD是什么? 持续集成(CI)/持续交付(CD)的优势自动化部署流程图 Git Github Gi ...
从服务器基础环境配置到搭建Docker+Gitlab+Gitlab Runner，完整介绍Spring Boot项目的持续集成与持续交付具体实现！
1. 序言在大学的课程学习,非常注重团队协作的培养,在企业开发中,团队协作开发项目的场景更是甚多.另外,在当下的热门技术栈中,微服务开发模式.前后端分离开发模式逐渐盛行,Spring Boot.VU ...
接口自动化持续集成实战
本文为实战练习,具体内容来自<接口自动化持续集成> 接口自动化测试持续集成主要包括以下内容. ① 流程方面.在回归阶段加强接口异常场景的覆盖,并逐步向系统测试.冒烟测试阶段延伸,最终达到全 ...
Jmeter+Jenkins+Ant 接口自动化持续集成框架
前言: 首先简单说下jmeter+jenkins+ant接口自动化持续集成框架的工作原理,以便于更好的理解后面的各项配置: 首先,jenkins通过SVN获取jmeter最新的脚本: 然后,jenki ...
自动化持续集成Jenkins
自动化持续集成Jenkins 使用Jenkins配置自动化构建 http://blog.csdn.net/littlechang/article/details/8642149 Jenkins入门总结 ...

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

一、基本概念

二、配置 workflow

① workflow 的配置

② workflow 的基本字段

三、Kingfisher

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

最新文章

热门文章