一、基本概念

• 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。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的GitHub之GitHub Actions的项目自动化持续集成和部署的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。