GitHub 操作的工作流程语法

A workflow is a configurable automated process made up of one or more jobs. You must create a YAML file to define your workflow configuration.

GitHub 操作可用于 GitHub Free、GitHub Pro、GitHub Team、GitHub Enterprise Cloud 和 GitHub One。 GitHub 操作不适用于使用旧版每仓库计划的公共或私有仓库。更多信息请参阅“GitHub 的产品”。

本文内容

关于工作流程的 YAML 语法

工作流程文件使用 YAML 语法，必须有 .yml 或 .yaml 文件扩展名。如果您是 YAML 的新用户并想要了解更多信息，请参阅“五分钟了解 YAML”。

必须将工作流程文件存储在仓库的 .github/workflows 目录中。

使用限制

GitHub 操作的使用有一些限制。除非另有指定，否则以下限制仅适用于 GitHub 托管的运行器，而不适用于自托管运行器。这些限制可能会有变动。

每个仓库可以同时执行最多 20 个工作流程。如果超出，任何额外的工作流程都会排队。
工作流程中每项作业的最长执行时间为 6 小时。如果作业达到此限制，该作业将会终止而无法完成。
可在帐户所有仓库中同时运行的作业数量取决于您的 GitHub 计划。如果超出，任何额外的作业都会排队。

GitHub 计划同时运行的作业总数 MacOS 作业同时运行的最大数量

免费 20 5

Pro 40 5

团队 60 5

企业 180 15
一个仓库中所有操作在一小时内最多可以执行 1000 条 API 请求。此限制也适用于自托管运行器。如果超出，额外的 API 调用将失败，这可能导致作业失败。

`name`

工作流程的名称。 GitHub 在仓库的操作页面上显示工作流程的名称。 If you omit name, GitHub sets it to the workflow file path relative to the root of the repository.

`on`

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

使用单一事件的示例

# Trigger on push
on: push

使用事件列表的示例

# Trigger the workflow on push or pull request
on: [push, pull_request]

使用具有活动类型或配置的多个事件示例

如果您需要为一个事件指定活动类型或配置，必须分别配置每个事件。您必须为所有事件附加冒号 (`:</0)，包括没有配置的事件。

on:
  # Trigger the workflow on push or pull request,
  # but only for the master branch
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration does not affect the page_build event above
      - created
`

`on.<event_name>.types`

选择将触发工作流程运行的活动类型。大多数 GitHub 事件由多种活动触发。例如，发布资源的事件在发行版 published、unpublished、created、edited、deleted 或 prereleased 时触发。通过 types 关键词可缩小触发工作流程运行的活动类型的范围。如果只有一种活动类型可触发 web 挂钩事件，就没有必要使用 types 关键词。

您可以使用事件 types 的数组。有关每个事件及其活动类型的更多信息，请参阅“触发工作流程的事件”。

# Trigger the workflow on pull request activity
on:
  release:
    # Only use the types keyword to narrow down the activity types that will trigger your workflow.
    types: [published, created, edited]

`on.<push|pull_request>.<branches|tags>`

使用 push 和 pull_request 事件时，您可以将工作流配置为在特定分支或标记上运行。 For a pull_request event, only branches and tags on the base are evaluated. If you define only tags or only branches, the workflow won't run for events affecting the undefined Git ref.

branches、branches-ignore、tags 和 tags-ignore 关键词接受使用 * 和 ** 通配符匹配多个分支或标记名称的 glob 模式。更多信息请参阅“过滤器模式备忘清单”。

包括分支和标记的示例

在 branches 和 tags 中定义的模式根据 Git ref 的名称进行评估。例如，在 branches 中定义的模式 mona/octocat 将匹配 refs/heads/mona/octocat Git ref。模式 releases/** 将匹配 refs/heads/releases/10 Git ref。

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:    
      - master         # Push events on master branch
      - 'mona/octocat' # Push events to branches matching refs/heads/mona/octocat
      - 'releases/**'  # Push events to branches matching refs/heads/releases/10
    # Sequence of patterns matched against refs/tags
    tags:        
      - v1             # Push events to v1 tag
      - v1.*           # Push events to v1.0, v1.1, and v1.9 tags

忽略分支和标记的示例

只要模式与 branches-ignore or tags-ignore 模式匹配，工作流就不会运行。在 branches-ignore 和 tags-ignore 中定义的模式根据 Git ref 的名称进行评估。例如，在 branches 中定义的模式 mona/octocat 将匹配 refs/heads/mona/octocat Git ref。 branches 中的模式 releases/**-alpha 将匹配 refs/releases/beta/3-alpha Git ref。

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'      # Push events to branches matching refs/heads/mona/octocat
      - 'releases/**-alpha' # Push events to branches matching refs/heads/releases/beta/3-alpha
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v1.*           # Push events to tags v1.0, v1.1, and v1.9

排除分支和标记

您可以使用两种类型的过滤器来阻止工作流程在对标记和分支的推送和拉取请求上运行。

branches 或 branches-ignore - 您无法对工作流程中的同一事件同时使用 branches 和 branches-ignore 过滤器。需要过滤肯定匹配的分支和排除分支时，请使用 branches 过滤器。只需要排除分支名称时，请使用 branches-ignore 过滤器。
tags 或 tags-ignore - 您无法对工作流程中的同一事件同时使用 tags 和 tags-ignore 过滤器。需要过滤肯定匹配的标记和排除标记时，请使用 tags 过滤器。只需要排除标记名称时，请使用 tags-ignore 过滤器。

使用肯定和否定模式的示例

您可以使用 ! 字符排除 tags 和 branches。您定义模式事项的顺序。

肯定匹配后的匹配否定模式（前缀为 !）将排除 Git 引用。
否定匹配后的匹配肯定模式将再次包含 Git 引用。

以下工作流程将在到 releases/10 或 releases/beta/mona 的推送上运行，而不会在到 releases/10-alpha 或 releases/beta/3-alpha 的推送上运行，因为否定模式 !releases/**-alpha 后跟肯定模式。

on:
  push:
    branches:    
    - 'releases/**'
    - '!releases/**-alpha'

`on.<push|pull_request>.paths`

使用 push 和 pull_request 事件时，您可以将工作流程配置为在至少一个文件不匹配 paths-ignore 或至少一个修改的文件匹配配置的 paths 时运行。路径过滤器不评估是否推送到标签。

paths-ignore 和 paths 关键词接受使用 * 和 ** 通配符匹配多个路径名称的 glob 模式。更多信息请参阅“过滤器模式备忘清单”。

忽略路径的示例

任何时候路径名称匹配 paths-ignore 中的模式，则工作流程不会运行。 GitHub 根据路径名称评估 paths-ignore 中定义的模式。具有以下路径过滤器的工作流程仅在 push 事件上运行，这些事件包括至少一个位于仓库根目录的 docs 目录外的文件。

on:
  push:
    paths-ignore:
    - 'docs/**'

包括路径的示例

如果至少有一个路径与 paths 过滤器中的模式匹配，工作流程将会运行。要在每次推送 JavaScript 文件时触发构建，您可以使用通配符模式。

on:
  push:
    paths:
    - '**.js'

排除路径

您可以使用两种类型的过滤器排除路径。不能对工作流程中的同一事件同时使用这两种过滤器。

paths-ignore - 只需要排除路径名称时，请使用 paths-ignore 过滤器。
paths - 需要过滤肯定匹配的路径和排除路径时，请使用 paths 过滤器。

使用肯定和否定模式的示例

您可以使用 ! 字符排除 paths。您定义模式事项的顺序：

肯定匹配后的匹配否定模式（前缀为 !）将排除路径。
否定匹配后的匹配肯定模式将再次包含路径。

只要 push 事件包括 sub-project 目录或其子目录中的文件，此示例就会运行，除非该文件在 sub-project/docs 目录中。例如，更改了 sub-project/index.js 或 sub-project/src/index.js 的推送将会触发工作流程运行，但只更改 sub-project/docs/readme.md 的推送不会触发。

on:
  push:
    paths:
    - 'sub-project/**'
    - '!sub-project/docs/**'

Git 差异比较

注：如果您推送超过 1,000 项提交，或者如果 GitHub 因超时（差异过大）未生成差异，工作流程将始终运行。

过滤器决定是否应通过评估已更改文件，并根据 paths-ignore or paths 列表运行它们，来运行一个工作流程。如果没有更改文件，工作流程将不会运行。

GitHub 会针对推送使用双点差异，针对拉取请求使用三点差异，生成已更改文件列表：

拉取请求： 三点差异比较主题分支的最近版本与其中使用基本分支最新同步主题分支的提交。
推送到现有分支： 双点差异可以直接相互比较头部和基础 SHA。
推送到新分支：根据已推送最深提交的前身父项的两点差异。

更多信息请参阅“关于比较拉取请求中的分支”。

`on.schedule`

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

此示例每隔 15 分钟触发工作流程：

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '*/15 * * * *'

For more information about cron syntax, see "Events that trigger workflows."

`env`

环境变量的 map 可用于工作流程中的所有作业和步骤。您还可以设置仅适用于作业或步骤的环境变量。更多信息请参阅 jobs.<job_id>.env and jobs.<job_id>.steps.env。

当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的环境变量。例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流程变量。为作业定义的变量在作业执行时将覆盖名称相同的工作流程变量。

示例

env:
  SERVER: production

`jobs`

工作流程运行包括一项或多项作业。作业默认是并行运行。要按顺序运行作业，您可以使用 <job_id>needs 关键词在其他作业上定义依赖项。

Each job runs in an environment specified by runs-on.

在工作流程的使用限制之内可运行无限数量的作业。更多信息请参阅“使用限制”。

`jobs.<job_id>`

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

示例

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

`jobs.<job_id>.name`

作业显示在 GitHub 上的名称。

`jobs.<job_id>.needs`

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

示例

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

在此示例中，job1 必须在 job2 开始之前成功完成，而 job3 要等待 job1 和 job2 完成。

此示例中的作业按顺序运行：

job1
job2
job3

`jobs.<job_id>.runs-on`

Required The type of machine to run the job on. The machine can be either a GitHub-hosted runner, or a self-hosted runner.

GitHub-hosted runners

If you use a GitHub-hosted runner, each job runs in a fresh instance of a virtual environment specified by runs-on.

Available GitHub-hosted runner types are:

虚拟环境	YAML 工作流程标签
Windows Server 2019	`windows-latest`
Ubuntu 18.04	`ubuntu-latest` 或 `ubuntu-18.04`
Ubuntu 16.04	`ubuntu-16.04`
macOS Catalina 10.15	`macos-latest`

示例

runs-on: ubuntu-latest

For more information, see "Virtual environments for GitHub-hosted runners."

Self-hosted runners

要为工作指定自托管的运行器，请在工作流程文件中使用自托管运行器标签配置 runs-on。

所有自托管的运行器都有 self-hosted 标签，您可以只提供 self-hosted 标签来选择任何自托管运行器。您也可以在一个带附加标签（例如用于特定操作系统或系统架构的标签）的数组中使用 self-hosted，只选择您指定的运行器类型。

示例

runs-on: [self-hosted, linux]

For more information, see "About self-hosted runners" and "Using self-hosted runners in a workflow."

`jobs.<job_id>.env`

环境变量的 map 可用于作业中的所有步骤。您也可以设置整个工作流程或单个步骤的环境变量。更多信息请参阅 env 和 jobs.<job_id>.steps.env。

当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的环境变量。例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流程变量。为作业定义的变量在作业执行时将覆盖名称相同的工作流程变量。

示例

jobs:
  job1:
    env:
      FIRST_NAME: Mona

`jobs.<job_id>.if`

您可以使用 if 条件阻止作业在条件得到满足之前运行。您可以使用任何支持上下文和表达式来创建条件。

if 条件中的表达式不需要 ${{ }} 语法。更多信息请参阅“GitHub 操作的上下文和表达式语法”。

`jobs.<job_id>.steps`

作业包含一系列任务，称为 steps。步骤可以运行命令、运行设置任务，或者运行您的仓库、公共仓库中的操作或 Docker 注册表中发布的操作。并非所有步骤都会运行操作，但所有操作都会作为步骤运行。 Each step runs in its own process in the runner environment and has access to the workspace and filesystem. 因为步骤以自己的进程运行，所以步骤之间不会保留环境变量的更改。 GitHub 提供内置的步骤来设置和完成作业。

在工作流程的使用限制之内可运行无限数量的步骤。更多信息请参阅“使用限制”。

示例

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.

`jobs.<job_id>.steps.id`

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

`jobs.<job_id>.steps.if`

您可以使用 if 条件阻止步骤在条件得到满足之前运行。您可以使用任何支持上下文和表达式来创建条件。

if 条件中的表达式不需要 ${{ }} 语法。更多信息请参阅“GitHub 操作的上下文和表达式语法”。

使用上下文的示例

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

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

使用状态检查功能的示例

my backup step 仅在作业的上一步失败时运行。 For more information, see "Contexts and expression syntax for GitHub 操作."

steps:
  - name: My first step
    # Use an action (`my-action`) in your repository
    uses: ./.github/actions/my-action
  - name: My backup step
    if: failure()
    uses: actions/heroku@master

`jobs.<job_id>.steps.name`

步骤显示在 GitHub 上的名称。

`jobs.<job_id>.steps.uses`

选择要作为作业中步骤的一部分运行的操作。操作是一种可重复使用的代码单位。您可以使用工作流程所在仓库中、公共仓库中或发布 Docker 容器映像中定义的操作。

强烈建议指定 Git ref、SHA 或 Docker 标记编号来包含所用操作的版本。如果不指定版本，在操作所有者发布更新时可能会中断您的工作流程或造成非预期的行为。

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

有些操作要求必须通过 with 关键词设置输入。请查阅操作的自述文件，确定所需的输入。

操作为 JavaScript 文件或 Docker 容器。 If the action you're using is a Docker container you must run the job in a Linux environment. For more details, see runs-on.

使用版本化操作的示例

steps:    
  - uses: actions/setup-node@74bc508 # Reference a specific commit
  - uses: actions/setup-node@v1      # Reference the major version of a release   
  - uses: actions/setup-node@v1.2    # Reference a minor version of a release  
  - uses: actions/setup-node@master  # Reference a branch

使用公共操作的示例

{owner}/{repo}@{ref}

您可以指定公共 GitHub 仓库中特定的分支、引用或 SHA。

jobs:
  my_first_job:
    steps:
      - name: My first step
      # Uses the master branch of a public repository
        uses: actions/heroku@master
      # use a specific version tag of a public repository
      - name: My second step
        uses: actions/aws@v2.0.1

在子目录中使用公共操作的示例

{owner}/{repo}/{path}@{ref}

公共 GitHub 仓库中特定分支、引用或 SHA 上的子目录。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/aws/ec2@master

使用工作流程所在仓库中操作的示例

./path/to/dir

包含工作流程的仓库中操作的目录路径。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: ./.github/actions/my-action

使用 Docker 中枢操作的示例

docker://{image}:{tag}

Docker 中枢上发布的 Docker 映像。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

使用 Docker 公共注册表操作的示例

docker://{host}/{image}:{tag}

公共注册表中的 Docker 映像。

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://gcr.io/cloud-builders/gradle

`jobs.<job_id>.steps.run`

使用操作系统 shell 运行命令行程序。如果不提供 name，步骤名称将默认为 run 命令中指定的文本。

命令默认使用非登录 shell 运行。您可以选择不同的 shell，也可以自定义用于运行命令的 shell。更多信息请参阅“使用指定 shell”。

Each run keyword represents a new process and shell in the runner environment. 当您提供多行命令时，每行都在同一个 shell 中运行。例如：

单行命令：

- name: Install Dependencies
  run: npm install

多行命令：

- name: Clean install dependencies and build
  run: |
    npm ci
    npm run build

使用 working-directory 关键词，您可以指定运行命令的工作目录位置。

- name: Clean temp directory
  run: rm -rf *
  working-directory: ./temp

使用指定 shell

You can override the default shell settings in the runner's operating system using the shell keyword. 您可以使用内置的 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	`powershell`	这是 Windows 上使用的默认 shell。 Desktop PowerShell。 GitHub 将扩展名 `.ps1` 附加到您的脚本名称。	`powershell -command "& '{0}'"`.

使用 bash 运行脚本的示例

steps:
  - name: Display the path
    run: echo $PATH
    shell: bash

使用 Windows `cmd` 运行脚本的示例

steps:
  - name: Display the path
    run: echo %PATH%
    shell: cmd

使用 PowerShell Core 运行脚本的示例

steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: pwsh

运行 python 脚本的示例

steps:
  - name: Display the path
    run: |
      import os
      print(os.environ['PATH'])
    shell: python

自定义 shell

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

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

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

bash/sh：
- 使用 set -e o 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.<job_id>.steps.with`

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

示例

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

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/hello_world@master
        with:
          first_name: Mona
          middle_name: The
          last_name: Octocat

`jobs.<job_id>.steps.with.args`

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

示例

steps:
  - name: Explain why this job ran
    uses: monacorp/action-name@master
    with:
      entrypoint: /bin/echo
      args: The ${{ github.event_name }} event triggered this step.

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

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

`jobs.<job_id>.steps.with.entrypoint`

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

示例

steps:
  - name: Run a custom command
    uses: monacorp/action-name@master
    with:
      entrypoint: /a/different/executable

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

`jobs.<job_id>.steps.env`

Sets environment variables for steps to use in the runner environment. 您也可以设置整个工作流程或某个作业的环境变量。更多信息请参阅 env 和 jobs.<job_id>.env。

当多个环境变量使用相同的名称定义时，GitHub 会使用最特定的环境变量。例如，步骤中定义的环境变量在步骤执行时将覆盖名称相同的作业和工作流程变量。为作业定义的变量在作业执行时将覆盖名称相同的工作流程变量。

公共操作可在自述文件中指定预期的环境变量。如果要在环境变量中设置密码，必须使用 secrets 上下文进行设置。 For more information, see "Using environment variables" and "Contexts and expression syntax for GitHub 操作."

示例

steps:
  - name: My first action
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      FIRST_NAME: Mona
      LAST_NAME: Octocat

`jobs.<job_id>.steps.continue-on-error`

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

`jobs.<job_id>.steps.timeout-minutes`

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

`jobs.<job_id>.timeout-minutes`

The maximum number of minutes to let a job run before GitHub automatically cancels it. 默认值：360

`jobs.<job_id>.strategy`

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

`jobs.<job_id>.strategy.matrix`

A build matrix is a set of different configurations of the runner environment. 例如，您可能在多个支持的语言、操作系统或工具版本上运行作业。每项配置是运行并报告状态的作业的副本。

您可以提供配置选项阵列来指定矩阵。 For example, if the runner environment supports Node.js versions 6, 8, and 10, you could specify an array of those versions in the matrix.

在定义操作系统矩阵时，必须为当前作业的操作系统设置必要的 runs-on 关键词，而不是对操作系统名称进行硬编码。要访问操作系统名称，可以使用 matrix.os 环境参数设置 runs-on。更多信息请参阅“GitHub 操作的上下文和表达式语法”。

在工作流程的使用限制之内可运行无限数量的作业。更多信息请参阅“使用限制”。

示例

此示例创建一个由三个作业组成的矩阵，将 node 变量设置为用于每个作业时都不同的值，并将该变量用作 setup-node 操作的输入。因此，每个作业将使用不同的节点版本。

strategy:
  matrix:
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

您还可以用两个的 Linux 版本运行这些作业，将矩阵变量用作 runs-on 说明符的输入，从而创建总共 6 个作业（3 个节点版本 x 2 个 Linux 版本）。

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

To find supported configuration options for GitHub-hosted runners, see "Virtual environments for GitHub-hosted runners."

在矩阵构建中包括配置的示例

您可以将额外的配置选项添加到已经存在的构建矩阵作业中。不能使用 include 将新作业添加到构建矩阵中。 For example, if you want to use a specific version of npm when the job that uses windows-latest and version 4 of node runs, you can use include to specify that additional option.

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

从矩阵中排除配置的示例

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

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [macos-latest, windows-latest, ubuntu-18.04]
    node: [4, 6, 8, 10]
    exclude:
      # excludes node 4 on macOS
      - os: macos-latest
        node: 4

`jobs.<job_id>.strategy.fail-fast`

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

`jobs.<job_id>.strategy.max-parallel`

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

strategy:
  max-parallel: 2

`jobs.<job_id>.container`

用于运行作业中尚未指定容器的任何步骤的容器。如有步骤同时使用脚本和容器操作，则容器操作将运行为同一网络上使用相同卷挂载的同级容器。

若不设置 container，所有步骤将直接在 runs-on 指定的主机上运行，除非步骤引用已配置为在容器中运行的操作。

示例

jobs:
  my_job:
    container:
      image: node:10.16-jessie
      env:
        NODE_ENV: development
      ports:
        - 80
      volumes:
        - my_docker_volume:/volume_mount
      options: --cpus 1

只指定容器映像时，可以忽略 image 关键词。

jobs:
  my_job:
    container: node:10.16-jessie

`jobs.<job_id>.container.image`

要用作运行操作的容器的 Docker 图像。值可以是 Docker 中枢映像名称或公共 Docker 注册表名称。

`jobs.<job_id>.container.env`

设置容器中环境变量的 array。

`jobs.<job_id>.container.ports`

设置要在容器上显示的端口 array。

`jobs.<job_id>.container.volumes`

设置要使用的容器卷的 array。您可以使用卷分享作业中服务或其他步骤之间的数据。可以指定命名的 Docker 卷、匿名的 Docker 卷或主机上的绑定挂载。

要指定卷，需指定来源和目标路径：

<source>:<destinationPath>.

<source> 是主机上的卷名称或绝对路径，<destinationPath> 是容器中的绝对路径。

示例

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

`jobs.<job_id>.container.options`

附加 Docker 容器资源选项。有关选项列表，请参阅“docker create options”。

`jobs.<job_id>.services`

注意：如果在 Docker 容器中运行作业并使用 GitHub 托管的运行器，则必须使用 ubuntu-latest 运行器。如果使用的是自托管运行器，则运行器机器必须安装了任何必需的 Docker 软件，除非您的机器原生支持 Docker。有关支持的 GitHub 托管运行器的更多信息，请参阅“ GitHub 托管运行器的虚拟环境”。

Used to host service containers for a job in a workflow. Service containers are useful for creating databases or cache services like Redis. The runner automatically creates a Docker network and manages the life cycle of the service containers.

If you configure your job to run in a container, or your step uses container actions, you don't need to map ports to access the service or action. Docker automatically exposes all ports between containers on the same Docker user-defined bridge network. You can directly reference the service container by its hostname. The hostname is automatically mapped to the label name you configure for the service in the workflow.

If you configure the job to run directly on the runner machine and your step doesn't use a container action, you must map any required Docker service container ports to the Docker host (the runner machine). You can access the service container using localhost and the mapped port.

For more information about the differences between networking service containers, see "About service containers."

Example using localhost

This example creates two services: nginx and redis. When you specify the Docker host port but not the container port, the container port is randomly assigned to a free port. GitHub sets the assigned container port in the ${{job.services.<service_name>.ports}} context. In this example, you can access the service container ports using the ${{ job.services.nginx.ports['8080'] }} and ${{ job.services.redis.ports['6379'] }} contexts.

services:
  nginx:
    image: nginx
    # Map port 8080 on the Docker host to port 80 on the nginx container
    ports:
      - 8080:80
  redis:
    image: redis
    # Map TCP port 6379 on Docker host to a random free port on the Redis container
    ports:
      - 6379/tcp

<source>:<destinationPath>.

<source> 是主机上的卷名称或绝对路径，<destinationPath> 是容器中的绝对路径。

示例

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

`jobs.<job_id>.services.options`

附加 Docker 容器资源选项。有关选项列表，请参阅“docker create options”。

过滤器模式备忘清单

You can use special characters in path, branch, and tag filters.

*: Matches zero or more characters, but does not match the / character. For example, Octo* matches Octocat.
**: Matches zero or more of any character.
?: Matches zero or one single character. For example, Octoc?t matches Octocat.
+: Matches one or more of the proceeding character.
[] Matches one character listed in the brackets or included in ranges. Ranges can only include a-z, A-Z, and 0-9. For example, the range[0-9a-f] matches any digits or lowercase letter. For example, [CB]at matches Cat or Bat and [1-2]00 matches 100 and 200.
!: At the start of a pattern makes it negate previous positive patterns. It has no special meaning if not the first character.

The characters *, [, and ! are special characters in YAML. If you start a pattern with *, [, or !, you must enclose the pattern in quotes.

- '**/README.md' # valid
- **/README.md   # INVALID - creates a parse error that prevents your workflow from running

For more information about branch, tag, and path filter syntax, see "on.<push|pull_request>.<branches|tags>" and "on.<push|pull_request>.paths."

Patterns to match branches and tags

Pattern	Description	Example matches
`功能/*`	The `*` wildcard matches any character, but does not match slash (`/`).	-`feature/my-branch` -`feature/your-branch`
`功能/**`	The `**` wildcard matches any character including slash (`/`) in branch and tag names.	-`feature/beta-a/my-branch` -`feature/your-branch` -`feature/mona/the/octocat`
-`master` -`releases/mona-the-octcat`	Matches the exact name of a branch or tag name.	-`master` -`releases/mona-the-octocat`
`'*'`	Matches all branch and tag names that don't contain a slash (`/`). The `` character is a special character in YAML. When you start a pattern with ``, you must use quotes.	-`master` -`releases`
`'**'`	Matches all branch and tag names. This is the default behavior when you don't use a `branches` or `tags` filter.	-`all/the/branches` -`every/tag`
`'*功能'`	The `` character is a special character in YAML. When you start a pattern with ``, you must use quotes.	-`mona-feature` -`feature` -`ver-10-feature`
`v2*`	Matches branch and tag names that start with `v2`.	-`v2` -`v2.0` -`v2.9`
`v[12].[0-9]+.[0-9]+`	Matches all semantic versioning tags with major version 1 or 2	-`v1.10.1` -`v2.0.0`

Patterns to match file paths

Path patterns must match the whole path, and start from the repository's root.

Pattern	Description of matches	Example matches
`'*'`	The `` wildcard matches any character, but does not match slash (`/`). The `` character is a special character in YAML. When you start a pattern with `*`, you must use quotes.	-`README.md` -`server.rb`
`'*.jsx?'`	The `?` character matches zero or one of the preceding character.	-`page.js` -`page.jsx`
`'**'`	The `**` wildcard matches any character including slash (`/`). This is the default behavior when you don't use a `path` filter.	-`all/the/files.md`
`'*.js'`	The `*` wildcard matches any character, but does not match slash (`/`). Matches all `.js` files at the root of the repository.	-`app.js` -`index.js`
`'**.js'`	Matches all `.js` files in the repository.	-`index.js` -`js/index.js` -`src/js/app.js`
`文档/*`	All files within the root of the `docs` directory, at the root of the repository.	-`docs/README.md` -`docs/file.txt`
`文档/**`	Any files in the `/docs` directory at the root of the repository.	-`docs/README.md` -`docs/mona/octocat.txt`
`docs/*/.md`	A file with a `.md` suffix anywhere in the `docs` directory.	-`docs/README.md` -`docs/mona/hello-world.md` -`docs/a/markdown/file.md`
`'/文档/'`	Any files in a `docs` directory anywhere in the repository.	-`/docs/hello.md` -`dir/docs/my-file.txt` -`space/docs/plan/space.doc`
`'**/README.md'`	A README.md file anywhere in the repository.	-`README.md` -`js/README.md`
`'*/src/**'`	Any file in a folder with a `src` suffix anywhere in the repository.	-`a/src/app.js` -`my-src/code/js/app.js`
`'*/-post.md'`	A file with the suffix `-post.md` anywhere in the repository.	-`my-post.md` -`path/their-post.md`
`'*/migrate-.sql'`	A file with the prefix `migrate-` and suffix `.sql` anywhere in the repository.	-`migrate-10909.sql` -`db/migrate-v1.0.sql` -`db/sept/migrate-v1.sql`
-`*.md` -`!README.md`	Using an exclamation mark (`!`) in front of a pattern negates it. When a file matches a pattern and also matches a negative pattern defined later in the file, the file will not be included.	-`hello.md` Does not match -`README.md` -`docs/hello.md`
-`.md` -`!README.md` -`README`	Patterns are checked sequentially. A pattern that negates a previous pattern will re-include file paths.	-`hello.md` -`README.md` -`README.doc`

GitHub 计划	同时运行的作业总数	MacOS 作业同时运行的最大数量
免费	20	5
Pro	40	5
团队	60	5
企业	180	15

GitHub 操作的工作流程语法

问问别人

找不到要找的内容？

产品

平台

支持

公司