Github Actions是什麼？

Github Actions 官方介紹：GitHub Actions是一個持續整合和持續交付(CI/CD)平臺，允許您自動化構建、測試和部署管道。您可以建立構建和測試儲存庫中的每個拉取請求的工作流，或者將合併的拉取請求部署到生產中。
GitHub Actions不僅僅是DevOps，還允許您在儲存庫中發生其他事件時執行工作流。例如，當有人在您的儲存庫中建立新問題時，您可以執行一個工作流自動新增適當的標籤。
GitHub提供Linux、Windows和macOS虛擬機器。

Overview

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

大家知道，持續整合由很多操作組成，比如抓取程式碼、執行測試、登入遠端伺服器，釋出到第三方服務等等。GitHub 把這些操作就稱為 actions。

很多操作在不同專案裡面是類似的，完全可以共享。GitHub 注意到了這一點，想出了一個很妙的點子，允許開發者把每個操作寫成獨立的指令碼檔案，存放到程式碼倉庫，使得其他開發者可以引用。

如果你需要某個 action，不必自己寫複雜的指令碼，直接引用他人寫好的 action 即可，整個持續整合過程，就變成了一個 actions 的組合。這就是 GitHub Actions 最特別的地方。

GitHub 做了一個官方市場，可以搜尋到他人提交的 actions。另外，還有一個

上面說了，每個 action 就是一個獨立指令碼，因此可以做成程式碼倉庫，使用userName/repoName的語法引用 action。比如，actions/setup-node就表示github.com/actions/setup-node這個倉庫，它代表一個 action，作用是安裝 Node.js。事實上，GitHub 官方的 actions 都放在 github.com/actions 裡面。

既然 actions 是程式碼倉庫，當然就有版本的概念，使用者可以引用某個具體版本的 action。下面都是合法的 action 引用，用的就是 Git 的指標概念，詳見官方文件。

actions/setup-node@74bc508 # 指向一個 commit
actions/[email protected]    # 指向一個標籤
actions/setup-node@master  # 指向一個分支

基本概念

GitHub Actions 有一些自己的術語。

• workflow （工作流程）：持續整合一次執行的過程，就是一個 workflow。
• job （任務）：一個 workflow 由一個或多個 jobs 構成，含義是一次持續整合的執行，可以完成多個任務。
• step（步驟）：每個 job 由多個 step 構成，一步步完成。
• action （動作）：每個 step 可以依次執行一個或多個命令（action）。

workflow檔案

GitHub Actions 的配置檔案叫做 workflow 檔案，存放在程式碼倉庫的.github/workflows目錄。

workflow 檔案採用 YAML 格式，檔名可以任意取，但是字尾名統一為.yml，比如foo.yml。一個庫可以有多個 workflow 檔案。GitHub 只要發現.github/workflows目錄裡面有.yml檔案，就會自動執行該檔案。

workflow 檔案的配置欄位非常多，詳見 官方文件。下面是一些基本欄位。

• name
  工作流的名稱。GitHub在儲存庫的“Actions”選項卡上顯示工作流的名稱。如果省略name, GitHub將其設定為相對於儲存庫根的工作流檔案路徑。

  name: GitHub Actions Demo
  

• run-name
  由工作流生成的工作流執行的名稱。GitHub將工作流執行名稱顯示在儲存庫“Actions”選項卡上的工作流執行列表中。如果省略了run-name或只有空白，則執行名稱將被設定為工作流執行的特定於事件的資訊。例如，對於由push或pull_request事件觸發的工作流，它被設定為提交訊息。
  這個值可以包括表示式，可以引用 github-context 和 inputs-context。

  run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}
  

• on
  若要自動觸發工作流，請使用 on 定義哪些事件可以觸發工作流執行。 有關可用事件的列表，請參閱“觸發工作流的事件”。
  可以定義單個或多個可以觸發工作流的事件，或設定時間計劃。 還可以將工作流的執行限制為僅針對特定檔案、標記或分支更改。

  • 使用單個事件
    例如，當推送到工作流儲存庫中的任何分支時，將執行具有以下 on 值的工作流：

    on: push
    

  • 使用多個事件
    可以指定單個事件或多個事件。 例如，當推送到儲存庫中的任何分支或有人建立儲存庫的分支時，將執行具有以下 on 值的工作流：

    on: [push, fork]
    

  完整的事件列表，請檢視 官方文件 。除了程式碼庫事件，GitHub Actions 也支援外部事件觸發，或者定時執行。

• on.<push|pull_request>.<tags|branches>
  指定觸發事件時，可以限定分支或標籤。

  on:
    push:
      branches:
        - master
  

  上面程式碼指定，只有master分支發生push事件時，才會觸發 workflow。

• jobs.<job_id>.name
  workflow 檔案的主體是jobs欄位，表示要執行的一項或多項任務。
  jobs欄位裡面，需要寫出每一項任務的job_id，具體名稱自定義。job_id裡面的name欄位是任務的說明。

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

  上面程式碼的jobs欄位包含兩項任務，job_id分別是my_first_job和my_second_job。

• jobs.<job_id>.needs
  使用jobs.<job_id>.needs標識在此作業執行之前必須成功完成的任何作業。它可以是字串或字串陣列。如果作業失敗，所有需要它的作業都將被跳過，除非作業使用了導致作業繼續的條件表示式。如果一次執行包含一系列彼此需要的作業，則從故障點開始，失敗將應用於依賴鏈中的所有作業。
  示例：

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

  在本例中，jobb1必須在jobb2開始之前成功完成，job3等待job1和jobb2完成。
  本例中的job按順序執行:

  1. job1
  2. job2
  3. job3

• jobs.<job_id>.runs-on
runs-on欄位指定執行所需要的虛擬機器環境

  • 目標機器可以是 GitHub-hosted runner、larger runner 和 self-hosted runner。
  • 您可以根據分配給runners的標籤，或他們的組成員資格，或這些的組合來定位runners。
  • 您可以將run-on作為單個字串或字串陣列提供。
  • 如果指定字串陣列，工作流將在與所有指定的run-on值匹配的任何執行器上執行。
  • 如果你想在多臺機器上執行你的工作流，使用 jobs.<job_id>.strategy。

  GitHub-hosted runners
  如果你使用 GitHub-hosted runner，每個job都執行在由runs-on指定的runner映象的新例項中。
  可用的GitHub-hosted runners型別有：

  runner映象	YAML工作流標籤	說明
  Windows Server 2022	windows-latest 或 windows-2022	windows-latest 標籤當前使用 Windows Server 2022 執行器映像。
  Windows Server 2019	windows-2019
  Ubuntu 22.04	ubuntu-22.04
  Ubuntu 20.04	ubuntu-latest 或 ubuntu-20.04	ubuntu-latest 標籤目前正在轉換為 Ubuntu 22.04 執行器映像。 在轉換期間，標籤可能引用 Ubuntu 20.04 或 22.04 的執行器映像。 有關 詳細資訊，請參閱此 GitHub 部落格文章。
  Ubuntu 18.04 [已棄用]	ubuntu-18.04	遷移到 ubuntu-20.04 或 ubuntu-22.04。 有關詳細資訊，請參閱此 GitHub 部落格文章。
  macOS Monterey 12	macos-12
  macOS Big Sur 11	macos-latest 或 macos-11	macos-latest 標籤目前正在轉換為 macOS Monterey 12 執行器映像。 在轉換期間，標籤可能引用 macOS 11 或 12 的執行器映像。 有關詳細資訊，請參閱此 GitHub 部落格文章。
  macOS Catalina 10.15 [已棄用]	macos-10.15	遷移到 macOS-11 或 macOS-12。 有關詳細資訊，請參閱此 GitHub 部落格文章。

  注意：-latest runner映象是 GitHub 提供的最新穩定映象，但可能不是作業系統供應商提供的最新版本的作業系統。

  警告：beta 版映像和已棄用的映像“按原樣提供”、“包含全部錯誤”且“視可用性情況”提供，不在服務級別協議和保證的涵蓋範圍之內。 客戶支援可能不會涵蓋 Beta 版映像。

  示例：指定作業系統

  runs-on: ubuntu-latest
  

  有關詳細資訊，請參閱“About GitHub-hosted runners”。

• jobs.<job_id>.steps
job包含一系列稱為steps的任務。steps可以執行命令、執行安裝任務，或者在您的儲存庫、公共儲存庫或Docker登錄檔中釋出的操作中執行操作。並非所有steps都執行操作，但所有操作都作為steps執行。每個steps都在執行程式環境中自己的程序中執行，並且可以訪問工作空間和檔案系統。因為steps在它們自己的程序中執行，所以在steps之間不會保留對環境變數的更改。GitHub提供了設定和完成job的內建steps。
  只要在工作流使用限制內，您可以執行無限數量的步驟。有關更多資訊，請參閱github託管執行程式的“使用限制和計費”，以及自託管執行程式的“關於自託管執行程式”的使用限制。
  steps欄位指定每個 Job 的執行步驟，可以包含一個或多個步驟。每個步驟都可以指定以下三個欄位。

  • jobs.<job_id>.steps.name：步驟名稱。
  • jobs.<job_id>.steps.run：該步驟執行的命令或者 action。
  • jobs.<job_id>.steps.env：該步驟所需的環境變數。

  下面是一個完整的 workflow 檔案的範例。

  name: Greeting from Mona
  
  on: push
  
  jobs:
    my-job:
      name: My Job
      runs-on: ubuntu-latest
      steps:
        - name: Print a greeting
          env:
            MY_VAR: Hi there! My name is
            FIRST_NAME: Mona
            MIDDLE_NAME: The
            LAST_NAME: Octocat
          run: |
            echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.
  

  上面程式碼中，steps欄位只包括一個步驟。該步驟先注入四個環境變數，然後執行一條 Bash 命令。

以上內容來源於：
GitHub Actions 官方文件
GitHub Actions 入門教程（阮一峰老師部落格）