当前位置:   article > 正文

GitHub之GitHub Actions的项目自动化持续集成和部署_github action 可持续集成 跨平台 c++库

github action 可持续集成 跨平台 c++库
一、基本概念
  • 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。
声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/花生_TL007/article/detail/186013
推荐阅读
相关标签
  

闽ICP备14008679号