Github Actions是什麼？ Github Actions 官方介紹：GitHub Actions是一個持續集成和持續交付(CI/CD)平臺，允許您自動化構建、測試和部署管道。您可以創建構建和測試存儲庫中的每個拉取請求的工作流，或者將合併的拉取請求部署到生產中。 GitHub Actions ...
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。另外，還有一個 awesome actions 的倉庫，也可以找到不少 action。
上面說了，每個 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按順序運行:job1job2job3
-
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-2022windows-latest標簽當前使用 Windows Server 2022 運行器映像。Windows Server 2019 windows-2019Ubuntu 22.04 ubuntu-22.04Ubuntu 20.04 ubuntu-latest或ubuntu-20.04ubuntu-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-12macOS Big Sur 11 macos-latest或macos-11macos-latest標簽目前正在轉換為 macOS Monterey 12 運行器映像。 在轉換期間，標簽可能引用 macOS 11 或 12 的運行器映像。 有關詳細信息，請參閱此 GitHub 博客文章。macOS Catalina 10.15 [已棄用] macos-10.15遷移到 macOS-11或macOS-12。 有關詳細信息，請參閱此 GitHub 博客文章。註意：
-latestrunner鏡像是 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 入門教程（阮一峰老師博客）
