语法

主要是看了文档，做了一些整理

采用YAML书写，首先学会YAML
官方推荐这篇文章https://learnxinyminutes.com/docs/zh-cn/yaml-cn/
示例：

  1. name: GitHub Actions Demo # 名称
  2. on: [push] # 触发事件
  3. jobs: # 作业们
  4.   Explore-GitHub-Actions: # 具体作业
  5.     runs-on: ubuntu-latest # 运行机器
  6.     steps: # 步骤
  7.       # 运行
  8.       # 这里对应一个数组，并且数组里面是对象 [{run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."},...]
  9.       - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
  10.       - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
  11.       - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
  12.       # 这里对应数组中的一个元素 {name: "Check out repository code", uses: "actions/checkout@v2"}
  13.       - name: Check out repository code
  14.         uses: actions/checkout@v2
  15.       - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
  16.       - run: echo "🖥️ The workflow is now ready to test your code on the runner."
  17.       - name: List files in the repository
  18.         run: |
  19.           ls ${{ github.workspace }}
  20.       - run: echo "🍏 This job's status is ${{ job.status }}."

也可以借助AST网站工具https://astexplorer.net/读懂。

name

工作流程的名称。
GitHub 在仓库的操作页面上显示工作流程的名称。
如果省略 name，GitHub 将其设置为相对于仓库根目录的工作流程文件路径。

on

必须配置
此位触发工作流程的 GitHub 事件的名称。
您可以提供单一事件 string、事件的 array、事件 types 的 array 或事件配置 map，以安排工作流程的运行，或将工作流程的执行限于特定文件、标记或分支更改。 有关可用事件的列表，请参阅“触发工作流程的事件”。

单一事件

  1. on: push

事件列表

  1. on: [push, pull_request]

复杂配置请参考https://docs.github.com/cn/actions/reference/workflow-syntax-for-github-actions#on

on.schedule

您可以使用 POSIX cron 语法安排工作流程在特定的 UTC 时间运行。 预定的工作流程在默认或基础分支的最新提交上运行。 您可以运行预定工作流程的最短间隔是每 5 分钟一次。
此示例在每天 5:30 和 17:30 UTC 触发工作流程：

  1. on:
  2.   schedule:
  3.     # * is a special character in YAML so you have to quote this string
  4.     - cron:  '30 5,17 * * *'

有关计划任务语法的更多信息请参阅“触发工作流程的事件”。

env

环境变量的 map 可用于工作流程中所有作业的步骤。 您还可以设置仅适用于单个作业的步骤或单个步骤的环境变量。 更多信息请参阅 jobs..env and jobs..steps[*].env。
当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的环境变量。 例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流程变量。 为作业定义的变量在作业执行时将覆盖名称相同的工作流程变量。

  1. env:
  2.   SERVER: production

jobs

工作流程运行包括一项或多项作业。 作业默认是并行运行。 要按顺序运行作业，您可以使用 needs 关键词在其他作业上定义依赖项。
每个作业在 runs-on 指定的运行器环境中运行。
在工作流程的使用限制之内可运行无限数量的作业。 更多信息请参阅“使用限制和计费”（对于 GitHub 托管的运行器）和“关于自托管运行器”（对于自托管运行器使用限制）。
如果需要查找在工作流程运行中运行的作业的唯一标识符，可以使用 GitHub ApI。 更多信息请参阅“工作流程作业”。

jobs.

每项作业必须关联一个 ID。 键值 jobid 是一个字符串，其值是作业配置数据的映像。 必须将 替换为 jobs 对象唯一的字符串。 必须以字母或 开头，并且只能包含字母数字字符、- 或 _。

  1. jobs:
  2.   my_first_job:
  3.     name: My first job
  4.   my_second_job:
  5.     name: My second job

jobs..name

作业显示在 GitHub 上的名称。

jobs..needs

识别在此作业运行之前必须成功完成的任何作业。 它可以是一个字符串，也可以是字符串数组。 如果某个作业失败，则所有需要它的作业都会被跳过，除非这些作业使用让该作业继续的条件表达式。

要求相关工作成功

  1. jobs:
  2.   job1:
  3.   job2:
  4.     needs: job1
  5.   job3:
  6.     needs: [job1, job2]

在此示例中，job1 必须在 job2 开始之前成功完成，而 job3 要等待 job1 和 job2 完成。
此示例中的作业按顺序运行：
1 job1
2 job2
3 job3

不要求相关作业成功

  1. jobs:
  2.   job1:
  3.   job2:
  4.     needs: job1
  5.   job3:
  6.     if: always()
  7.     needs: [job1, job2]

在此示例中，job3 使用 always() 条件表达式，因此它始终在 job1 和 job2 完成后运行，不管它们是否成功。 更多信息请参阅“上下文和表达式语法”。

jobs..runs-on

必须配置。 要运行作业的机器类型。 机器可以是 GitHub 托管的运行器或自托管的运行器。

GitHub托管的运行器

如果使用 GitHub 托管的运行器，每个作业将在 runs-on 指定的虚拟环境的新实例中运行。
可用的 GitHub 托管的运行器类型包括：

虚拟环境 YAML 工作流程标签
Windows Server 2019 windows-latest 或 windows-2019
Windows Server 2016 windows-2016
Ubuntu 20.04 ubuntu-latest 或 ubuntu-20.04
Ubuntu 18.04 ubuntu-18.04
macOS Big Sur 11 macos-11
macOS Catalina 10.15 macos-latest 或 macos-10.15

注意：
MacOS 11 虚拟环境目前仅作为私人预览提供。 任何已经在使用此运行器的用户或组织都可以继续使用它。 但我们目前不接受任何其他用户或组织。 macos-latest YAML 工作流程标签仍使用 MacOS 10.15 虚拟环境。

例子：

  1. runs-on: ubuntu-latest

jobs..permissions

您可以修改授予 GITHUB_TOKEN 的默认权限，根据需要添加或删除访问权限，以便只授予所需的最低访问权限。 更多信息请参阅“工作流程中的身份验证。
通过在工作定义中指定权限，您可以根据需要为每个作业的 GITHUB_TOKEN 配置一组不同的权限。 或者，您也可以为工作流程中的所有作业指定权限。 有关在工作流程级别定义权限的信息，请参阅 permissions。

可用的作用域和访问权限值：

  1. permissions:
  2.   actions: read|write|none
  3.   checks: read|write|none
  4.   contents: read|write|none
  5.   deployments: read|write|none
  6.   issues: read|write|none
  7.   packages: read|write|none
  8.   pull-requests: read|write|none
  9.   repository-projects: read|write|none
  10.   security-events: read|write|none
  11.   statuses: read|write|none

如果您指定其中任何作用域的访问权限，则所有未指定的作用域都被设置为 none。
您可以使用以下语法来定义所有可用作用域的读取或写入权限：

  1. permissions: read-all|write-all

您可以使用 permissions 键来添加和删除复刻仓库的读取权限，但通常不能授予写入权限。 此行为的例外情况是，管理员在 GitHub Actions 设置中选择了 Send write tokens to workflows from pull requests（从拉取请求发送写入令牌到工作流程）选项。 更多信息请参阅“禁用或限制仓库的 GitHub Actions”。

示例：

  1. jobs:
  2.   stale:
  3.     runs-on: ubuntu-latest
  5.     permissions:
  6.       issues: write
  7.       pull-requests: write
  9.     steps:
  10.       - uses: actions/stale@v3

此示例显示为将要应用到作业 stale 的 GITHUB_TOKEN 设置的权限。 对于 issues 和 pull-requests 拉取请求，授予写入访问权限。 所有其他范围将没有访问权限。

jobs..environment

作业引用的环境。 在将引用环境的作业发送到运行器之前，必须通过所有环境保护规则。 更多信息请参阅“环境”。
您可以将环境仅作为环境 name，或作为具有 name 和 url 的环境变量。 URL 映射到部署 API 中的 environment_url。 有关部署 API 的更多信息，请参阅“部署”。

使用单一环境名称示例：

  1. environment: staging_environment

使用环境名称和URL的示例：

  1. environment:
  2.   name: production_environment
  3.   url: https://github.com

URL 可以是表达式，并且可以使用除 secrets 上下文以外的任何上下文。 有关表达式的更多信息，请参阅“GitHub Actions 的上下文和表达式语法”。
示例：

  1. environment:
  2.   name: production_environment
  3.   url: ${{ steps.step_id.outputs.url_output }}

jobs..outputs

作业的输出 map。 作业输出可用于所有依赖此作业的下游作业。 有关定义作业依赖项的更多信息，请参阅 jobs..needs。
作业输出是字符串，当每个作业结束时，在运行器上评估包含表达式的作业输出。 包含密码的输出在运行器上编辑，不会发送至 GitHub Actions。
要在依赖的作业中使用作业输出, 您可以使用 needs 上下文。 更多信息请参阅“GitHub Actions 的上下文和表达式语法”。

示例：

  1. jobs:
  2.   job1:
  3.     runs-on: ubuntu-latest
  4.     # Map a step output to a job output
  5.     outputs:
  6.       output1: ${{ steps.step1.outputs.test }}
  7.       output2: ${{ steps.step2.outputs.test }}
  8.     steps:
  9.       - id: step1
  10.         run: echo "::set-output name=test::hello"
  11.       - id: step2
  12.         run: echo "::set-output name=test::world"
  13.   job2:
  14.     runs-on: ubuntu-latest
  15.     needs: job1
  16.     steps:
  17.       - run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}

jobs..env

环境变量的 map 可用于作业中的所有步骤。 您也可以设置整个工作流程或单个步骤的环境变量。 更多信息请参阅 env 和 jobs..steps[*].env。
当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的环境变量。 例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流程变量。 为作业定义的变量在作业执行时将覆盖名称相同的工作流程变量。

示例：

  1. jobs:
  2.   job1:
  3.     env:
  4.       FIRST_NAME: Mona

jobs..defaults

将应用到作业中所有步骤的默认设置的 map。 您也可以设置整个工作流程的默认设置。 更多信息请参阅 defaults。
使用相同名称定义了多个默认设置时，GitHub 会使用最具体的默认设置。 例如，在作业中定义的默认设置将覆盖在工作流程中定义的同名默认设置。

jobs..defaults.run

为作业中的所有 run 步骤提供默认的 shell 和 working-directory。 此部分不允许上下文和表达式。
您可以为作业中的所有 run 步骤提供默认的 shell 和 working-directory 选项。 您也可以为整个工作流程设置 run 的默认设置。 更多信息请参阅 jobs.defaults.run。 您不能在此关键词中使用上下文或表达式。
使用相同名称定义了多个默认设置时，GitHub 会使用最具体的默认设置。 例如，在作业中定义的默认设置将覆盖在工作流程中定义的同名默认设置。

示例：

  1. jobs:
  2.   job1:
  3.     runs-on: ubuntu-latest
  4.     defaults:
  5.       run:
  6.         shell: bash
  7.         working-directory: scripts

jobs..if

您可以使用 if 条件阻止作业在条件得到满足之前运行。 您可以使用任何支持上下文和表达式来创建条件。
在 if 条件下使用表达式时，可以省略表达式语法 (${{ }})，因为 GitHub 会自动将 if 条件作为表达式求值，除非表达式包含任何运算符。 如果表达式包含任何运算符，则表达式必须包含在 ${{ }} 内，以明确标记它进行计算。 更多信息请参阅“GitHub Actions 的上下文和表达式语法”。

jobs..steps

作业包含一系列任务，称为 steps。 步骤可以运行命令、运行设置任务，或者运行您的仓库、公共仓库中的操作或 Docker 注册表中发布的操作。 并非所有步骤都会运行操作，但所有操作都会作为步骤运行。 每个步骤在运行器环境中以其自己的进程运行，且可以访问工作区和文件系统。 因为步骤以自己的进程运行，所以步骤之间不会保留环境变量的更改。 GitHub 提供内置的步骤来设置和完成作业。
在工作流程的使用限制之内可运行无限数量的步骤。 更多信息请参阅“使用限制和计费”（对于 GitHub 托管的运行器）和“关于自托管运行器”（对于自托管运行器使用限制）。

示例：

  1. name: Greeting from Mona
  3. on: push
  5. jobs:
  6.   my-job:
  7.     name: My Job
  8.     runs-on: ubuntu-latest
  9.     steps:
  10.       - name: Print a greeting
  11.         env:
  12.           MY_VAR: Hi there! My name is
  13.           FIRST_NAME: Mona
  14.           MIDDLE_NAME: The
  15.           LAST_NAME: Octocat
  16.         run: |
  17.           echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

jobs..steps[*].id

步骤的唯一标识符。 您可以使用 id 引用上下文中的步骤。 更多信息请参阅“GitHub Actions 的上下文和表达式语法”。

jobs..steps[*].if

您可以使用 if 条件阻止步骤在条件得到满足之前运行。 您可以使用任何支持上下文和表达式来创建条件。
在 if 条件下使用表达式时，可以省略表达式语法 (${{ }})，因为 GitHub 会自动将 if 条件作为表达式求值，除非表达式包含任何运算符。 如果表达式包含任何运算符，则表达式必须包含在 ${{ }} 内，以明确标记它进行计算。 更多信息请参阅“GitHub Actions 的上下文和表达式语法”。

使用上下文
此步骤仅在事件类型为 pull_request 并且事件操作为 unassigned 时运行。

  1. steps:
  2.  - name: My first step
  3.    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
  4.    run: echo This event is a pull request that had an assignee removed.

使用状态检查功能
my backup step 仅在作业的上一步失败时运行。 更多信息请参阅“GitHub Actions 的上下文和表达式语法”。

  1. steps:
  2.   - name: My first step
  3.     uses: monacorp/action-name@main
  4.   - name: My backup step
  5.     if: ${{ failure() }}
  6.     uses: actions/heroku@1.0.0

jobs..steps[*].name

步骤显示在 GitHub 上的名称。

jobs..steps[*].uses

选择要作为作业中步骤的一部分运行的操作。 操作是一种可重复使用的代码单位。 您可以使用工作流程所在仓库中、公共仓库中或发布 Docker 容器映像中定义的操作。
强烈建议指定 Git ref、SHA 或 Docker 标记编号来包含所用操作的版本。 如果不指定版本，在操作所有者发布更新时可能会中断您的工作流程或造成非预期的行为。

  • 使用已发行操作版本的 SHA 对于稳定性和安全性是最安全的。
  • 使用特定主要操作版本可在保持兼容性的同时接收关键修复和安全补丁。 还可确保您的工作流程继续工作。
  • 使用操作的默认分支可能很方便，但如果有人新发布具有突破性更改的主要版本，您的工作流程可能会中断。

有些操作要求必须通过 with 关键词设置输入。 请查阅操作的自述文件，确定所需的输入。
操作为 JavaScript 文件或 Docker 容器。 如果您使用的操作是 Docker 容器，则必须在 Linux 环境中运行作业。 更多详情请参阅 runs-on。

使用版本化操作

  1. steps:    
  2.   # Reference a specific commit
  3.   - uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e
  4.   # Reference the major version of a release
  5.   - uses: actions/setup-node@v1
  6.   # Reference a minor version of a release
  7.   - uses: actions/setup-node@v1.2
  8.   # Reference a branch
  9.   - uses: actions/setup-node@main

使用公共操作
{owner}/{repo}@{ref}
您可以指定公共 GitHub 仓库中特定的分支、引用或 SHA。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: My first step
  5.         # Uses the default branch of a public repository
  6.         uses: actions/heroku@1.0.0
  7.       - name: My second step
  8.         # Uses a specific version tag of a public repository
  9.         uses: actions/aws@v2.0.1

在子目录中使用公共操作
{owner}/{repo}/{path}@{ref}
公共 GitHub 仓库中特定分支、引用或 SHA 上的子目录。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: My first step
  5.         uses: actions/aws/ec2@main

使用工作流程所在的库操作
./path/to/dir
包含工作流程的仓库中操作的目录路径。 在使用操作之前，必须检出仓库。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: Check out repository
  5.         uses: actions/checkout@v2
  6.       - name: Use local my-action
  7.         uses: ./.github/actions/my-action

使用Docker中枢操作
docker://{image}:{tag}
Docker 中枢上发布的 Docker 映像。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: My first step
  5.         uses: docker://alpine:3.8

使用Docker公共注册表操作
docker://{host}/{image}:{tag}
公共注册表中的 Docker 映像。 此示例在 gcr.io 使用 Google Container Registry。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: My first step
  5.         uses: docker://gcr.io/cloud-builders/gradle

在不同于工作流程的私有仓库进行操作
您的工作流程必须检出私有仓库，并在本地引用操作。 生成个人访问令牌并将该令牌添加为加密密钥。 更多信息请参阅“创建个人访问令牌”和“加密密码”。
将示例中的 PERSONAL_ACCESS_TOKEN 替换为您的密钥名称。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: Check out repository
  5.         uses: actions/checkout@v2
  6.         with:
  7.           repository: octocat/my-private-repo
  8.           ref: v1.0
  9.           token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
  10.           path: ./.github/actions/my-private-repo
  11.       - name: Run my action
  12.         uses: ./.github/actions/my-private-repo/my-action

jobs..steps[*].run

使用操作系统 shell 运行命令行程序。 如果不提供 name，步骤名称将默认为 run 命令中指定的文本。
命令默认使用非登录 shell 运行。 您可以选择不同的 shell，也可以自定义用于运行命令的 shell。 更多信息请参阅“使用指定 shell”。
每个 run 关键词代表运行器环境中一个新的进程和 shell。 当您提供多行命令时，每行都在同一个 shell 中运行。 例如：

  • 单行命令 ```yaml

  • name: Install Dependencies run: npm install ```

  • 多行命令 ```yaml

  • name: Clean install dependencies and build run: | npm ci npm run build 使用 working-directory 关键词，您可以指定运行命令的工作目录位置。yaml
  • name: Clean temp directory run: rm -rf * working-directory: ./temp ``` 使用指定shell
    您可以使用 shell 关键词覆盖运行器操作系统中默认的 shell 设置。 您可以使用内置的 shell 关键词，也可以自定义 shell 选项集。
支持的平台 shell 参数 描述 内部运行命令
所有 bash 非 Windows 平台上回退到 sh 的默认 shell。 指定 Windows 上的 bash shell 时，将使用 Git for Windows 随附的 bash shel。 bash —noprofile —norc -eo pipefail {0}
所有 pwsh PowerShell Core。 GitHub 将扩展名 .ps1 附加到您的脚本名称。 pwsh -command “. ‘{0}’”
所有 python 执行 python 命令。 python {0}
Linux / macOS sh 未提供 shell 且 在路径中找不到 bash 时的非 Windows 平台的后退行为。 sh -e {0}
Windows cmd GitHub 将扩展名 .cmd 附加到您的脚本名称并替换 {0}。 %ComSpec% /D /E:ON /V:OFF /S /C “CALL “{0}””.
Windows pwsh 这是 Windows 上使用的默认 shell。 PowerShell Core。 GitHub 将扩展名 .ps1 附加到您的脚本名称。 如果自托管的 Windows 运行器没有安装 PowerShell Core，则使用 PowerShell Desktop 代替。 pwsh -command “. ‘{0}’”.
Windows powershell PowerShell 桌面。 GitHub 将扩展名 .ps1 附加到您的脚本名称。 powershell -command “. ‘{0}’”.

使用bash运行脚本

  1. steps:
  2.   - name: Display the path
  3.     run: echo $PATH
  4.     shell: bash

使用windows cmd运行脚本

  1. steps:
  2.   - name: Display the path
  3.     run: echo %PATH%
  4.     shell: cmd

使用powershell core运行脚本

  1. steps:
  2.   - name: Display the path
  3.     run: echo ${env:PATH}
  4.     shell: pwsh

使用powershell桌面运行脚本

  1. steps:
  2.   - name: Display the path
  3.     run: echo ${env:PATH}
  4.     shell: powershell

运行python脚本

  1. steps:
  2.   - name: Display the path
  3.     run: |
  4.       import os
  5.       print(os.environ['PATH'])
  6.     shell: python

自定义shell

您可以使用 command […options] {0} [..more_options] 将 shell 值设置为模板字符串。 GitHub 将字符串的第一个用空格分隔的词解释为命令，并在 {0} 处插入临时脚本的文件名。
例如：

  1. steps:
  2.   - name: Display the environment variables and their values
  3.     run: |
  4.       print %ENV
  5.     shell: perl {0}

此示例中使用的命令 perl 必须安装在运行器上。
有关 GitHub 托管运行器中所包含软件的信息，请参阅“GitHub 托管运行器的规格”。

退出代码和错误操作首选项

至于内置的 shell 关键词，我们提供由 GitHub 托管运行程序执行的以下默认值。 在运行 shell 脚本时，您应该使用这些指南。

  • bash/sh：
    • 使用 set -eo pipefail 的快速失败行为：bash 和内置 shell 的默认值。 它还是未在非 Windows 平台上提供选项时的默认值。
    • 您可以向 shell 选项提供模板字符串，以退出快速失败并接管全面控制权。 例如 bash {0}。
    • sh 类 shell 使用脚本中最后执行的命令的退出代码退出，也是操作的默认行为。 运行程序将根据此退出代码将步骤的状态报告为失败/成功。
  • powershell/pwsh
    • 可能时的快速失败行为。 对于 pwsh 和 powershell 内置 shell，我们将 $ErrorActionPreference = ‘stop’ 附加到脚本内容。
    • 我们将 if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE } 附加到 powershell 脚本，以使操作状态反映脚本的最后一个退出代码。
    • 用户可随时通过不使用内置 shell 并提供类似如下的自定义 shell 选项来退出：pwsh -File {0} 或 powershell -Command “& ‘{0}’”，具体取决于需求。
  • cmd
    • 除了编写脚本来检查每个错误代码并相应地响应之外，似乎没有办法完全选择快速失败行为。 由于我们默认不能实际提供该行为，因此您需要将此行为写入脚本。
    • cmd.exe 在退出时带有其执行的最后一个程序的错误等级，并且会将错误代码返回到运行程序。 此行为在内部与上一个 sh 和 pwsh 默认行为一致，是 cmd.exe 的默认值，所以此行为保持不变。

jobs..steps[*].with

输入参数的 map 由操作定义。 每个输入参数都是一个键/值对。 输入参数被设置为环境变量。 该变量的前缀为 INPUT_，并转换为大写。

示例：

定义 hello_world 操作所定义的三个输入参数（first_name、middle_name 和 last_name）。 这些输入变量将被 hello-world 操作作为 INPUT_FIRST_NAME、INPUT_MIDDLE_NAME 和 INPUT_LAST_NAME 环境变量使用。

  1. jobs:
  2.   my_first_job:
  3.     steps:
  4.       - name: My first step
  5.         uses: actions/hello_world@main
  6.         with:
  7.           first_name: Mona
  8.           middle_name: The
  9.           last_name: Octocat

jobs..steps[*].with.args

string 定义 Docker 容器的输入。 GitHub 在容器启动时将 args 传递到容器的 ENTRYPOINT。 此参数不支持 array of strings。

示例：

  1. steps:
  2.   - name: Explain why this job ran
  3.     uses: monacorp/action-name@main
  4.     with:
  5.       entrypoint: /bin/echo
  6.       args: The ${{ github.event_name }} event triggered this step.

args 用来代替 Dockerfile 中的 CMD 指令。 如果在 Dockerfile 中使用 CMD，请遵循按偏好顺序排序的指导方针：

  1. 在操作的自述文件中记录必要的参数，并在 CMD 指令的中忽略它们。
  2. 使用默认值，允许不指定任何 args 即可使用操作。
  3. 如果操作显示 —help 标记或类似项，请将其用作默认值，以便操作自行记录。

jobs..steps[*].with.entrypoint

覆盖 Dockerfile 中的 Docker ENTRYPOINT，或在未指定时设置它。 与包含 shell 和 exec 表单的 Docker ENTRYPOINT 指令不同，entrypoint 关键词只接受定义要运行的可执行文件的单个字符串。

  1. steps:
  2.   - name: Run a custom command
  3.     uses: monacorp/action-name@main
  4.     with:
  5.       entrypoint: /a/different/executable

entrypoint 关键词旨在用于 Docker 容器操作，但您也可以将其用于未定义任何输入的 JavaScript 操作。

jobs..steps[*].env

设置供步骤用于运行器环境的环境变量。 您也可以设置整个工作流程或某个作业的环境变量。 更多信息请参阅 env 和 jobs..env。
当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的环境变量。 例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流程变量。 为作业定义的变量在作业执行时将覆盖名称相同的工作流程变量。
公共操作可在自述文件中指定预期的环境变量。 如果要在环境变量中设置密码，必须使用 secrets 上下文进行设置。 更多信息请参阅“使用环境变量”和“GitHub Actions 的上下文和表达式”。

示例：

  1. steps:
  2.   - name: My first action
  3.     env:
  4.       GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  5.       FIRST_NAME: Mona
  6.       LAST_NAME: Octocat

jobs..steps[*].continue-on-error

防止步骤失败时作业也会失败。 设置为 true 以允许在此步骤失败时作业能够通过。

jobs..steps[*].timeout-minutes

终止进程之前运行该步骤的最大分钟数。

jobs..timeout-minutes

在 GitHub 自动取消运行之前可让作业运行的最大分钟数。 默认值：360

jobs..strategy

策略创建作业的构建矩阵。 您可以定义要在其中运行每项作业的不同变种。

jobs..strategy.matrix

您可以定义不同作业配置的矩阵。 矩阵允许您通过在单个作业定义中执行变量替换来创建多个作业。 例如，可以使用矩阵为多个受支持的编程语言、操作系统或工具版本创建作业。 矩阵重新使用作业的配置，并为您配置的每个矩阵创建作业。
作业矩阵在每次工作流程运行时最多可生成 256 个作业。 此限制也适用于自托管运行器。
您在 matrix 中定义的每个选项都有键和值。 定义的键将成为 matrix 上下文中的属性，您可以在工作流程文件的其他区域中引用该属性。 例如，如果定义包含操作系统数组的键 os，您可以使用 matrix.os 属性作为 runs-on 关键字的值，为每个操作系统创建一个作业。 更多信息请参阅“GitHub Actions 的上下文和表达式语法”。
定义 matrix 事项的顺序。 定义的第一个选项将是工作流程中运行的第一个作业。

示例：

运行多个版本的node.js

  1. strategy:
  2.   matrix:
  3.     node: [10, 12, 14]
  4. steps:
  5.   # Configures the node version used on GitHub-hosted runners
  6.   - uses: actions/setup-node@v2
  7.     with:
  8.       # The Node.js version to configure
  9.       node-version: ${{ matrix.node }}

setup-node 操作是在使用 GitHub 托管的运行器时建议用于配置 Node.js 版本的方式。 更多信息请参阅 setup-node 操作。

使用多个操作系统运行

您可以创建矩阵以在多个运行器操作系统上运行工作流程。 您也可以指定多个矩阵配置。 此示例创建包含 6 个作业的矩阵：

  • 在 os 阵列中指定了 2 个操作系统
  • 在 node 阵列中指定了 3 个 Node.js 版本

定义操作系统矩阵时，必须将 runs-on 的值设置为您定义的 matrix.os 上下文属性。

  1. runs-on: ${{ matrix.os }}
  2. strategy:
  3.   matrix:
  4.     os: [ubuntu-18.04, ubuntu-20.04]
  5.     node: [10, 12, 14]
  6. steps:
  7.   - uses: actions/setup-node@v2
  8.     with:
  9.       node-version: ${{ matrix.node }}

要查找 GitHub 托管的运行器支持的配置选项，请参阅“GitHub 托管的运行器的虚拟环境”。

在组合中包含附加值

您可以将额外的配置选项添加到已经存在的构建矩阵作业中。 例如，如果要在作业使用 windows-latest 和 node 的版本 8 运行时使用 npm 的特定版本，您可以使用 include 指定该附加选项。

  1. runs-on: ${{ matrix.os }}
  2. strategy:
  3.   matrix:
  4.     os: [macos-latest, windows-latest, ubuntu-18.04]
  5.     node: [8, 10, 12, 14]
  6.     include:
  7.       # includes a new variable of npm with a value of 6
  8.       # for the matrix leg matching the os and version
  9.       - os: windows-latest
  10.         node: 8
  11.         npm: 6

包括新组合

您可以使用 include 将新作业添加到构建矩阵中。 任何不匹配包含配置都会添加到矩阵中。 例如，如果您想要使用 node 版本 14 在多个操作系统上构建，但在 Ubuntu 上需要一个使用节点版本 15 的额外实验性作业，则可使用 include 指定该额外作业。

  1. runs-on: ${{ matrix.os }}
  2. strategy:
  3.   matrix:
  4.     node: [14]
  5.     os: [macos-latest, windows-latest, ubuntu-18.04]
  6.     include:
  7.       - node: 15
  8.         os: ubuntu-18.04
  9.         experimental: true

从矩阵中排除配置

您可以使用 exclude 选项删除构建矩阵中定义的特定配置。 使用 exclude 删除由构建矩阵定义的作业。 作业数量是您提供的数组中所包括的操作系统 (os) 数量减去所有减项 (exclude) 后的叉积。

  1. runs-on: ${{ matrix.os }}
  2. strategy:
  3.   matrix:
  4.     os: [macos-latest, windows-latest, ubuntu-18.04]
  5.     node: [8, 10, 12, 14]
  6.     exclude:
  7.       # excludes node 8 on macOS
  8.       - os: macos-latest
  9.         node: 8

注意：所有 include 组合在 exclude 后处理。 这允许您使用 include 添加回以前排除的组合。

在矩阵中使用环境变量

您可以使用 include 键为每个测试组合添加自定义环境变量。 然后，您可以在后面的步骤中引用自定义环境变量。
在此示例中， node-version 的矩阵条目每个都被配置为对 site 和 datacenter 环境变量使用不同的值。 Echo site details 步骤然后使用 env: ${{ matrix.env }} 引用自定义变量：

  1. name: Node.js CI
  2. on: [push]
  3. jobs:
  4.   build:
  5.     runs-on: ubuntu-latest
  6.     strategy:
  7.       matrix:
  8.        include:
  9.          - node-version: 10.x
  10.            site: "prod"
  11.            datacenter: "site-a"
  12.          - node-version: 12.x
  13.            site: "dev"
  14.            datacenter: "site-b"
  15.     steps:
  16.       - name: Echo site details
  17.         env:
  18.           SITE: ${{ matrix.site }}
  19.           DATACENTER: ${{ matrix.datacenter }}
  20.         run: echo $SITE $DATACENTER

jobs..strategy.fail-fast

设置为 true 时，如果任何 matrix 作业失败，GitHub 将取消所有进行中的作业。 默认值：true

jobs..strategy.max-parallel

使用 matrix 作业策略时可同时运行的最大作业数。 默认情况下，GitHub 将最大化并发运行的作业数量，具体取决于 GitHub 托管虚拟机上可用的运行程序。

  1. strategy:
  2.   max-parallel: 2

jobs..continue-on-error

防止工作流程运行在作业失败时失败。 设置为 true 以允许工作流程运行在此作业失败时通过。

防止特定失败的矩阵无法运行工作流程

您可以允许作业矩阵中的特定任务失败，但工作流程运行不失败。 例如， 只允许 node 设置为 15 的实验性作业失败，而不允许工作流程运行失败。

  1. runs-on: ${{ matrix.os }}
  2. continue-on-error: ${{ matrix.experimental }}
  3. strategy:
  4.   fail-fast: false
  5.   matrix:
  6.     node: [13, 14]
  7.     os: [macos-latest, ubuntu-18.04]
  8.     experimental: [false]
  9.     include:
  10.       - node: 15
  11.         os: ubuntu-18.04
  12.         experimental: true

参考

https://docs.github.com/cn/actions/reference/workflow-syntax-for-github-actions