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/setup-node@v1.0    # 指向一个标签 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 入门教程（阮一峰老师博客）