关于工作流程
工作流程是一个可配置的自动化过程,它将运行一个或多个作业。 工作流程由签入到存储库的 YAML 文件定义,并在存储库中的事件触发时运行,也可以手动触发,或按定义的时间表触发。
Workflows are defined in the .github/workflows
directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks. 例如,您可以有一个工作流程来构建和测试拉取请求,另一个工作流程用于在每次创建发布时部署应用程序,还有一个工作流程在每次有人打开新议题时添� � �签。
工作流程基础知识
工作流程必须包含以下基本组件:
- 将触发工作流程的一个或多个事件。
- 一个或多个作业,每个作业将在运行器计算机上执行,并运行一系列一个或多个步骤。
- 每个步骤都可以运行您定义的脚本,也可以运行操作,这是一个可重用的扩展,可以简化您的工作流程。
有关这些基本组件的详细信息,请参阅“了解 GitHub Actions”。
触发工作流程
工作流程触发器是导致工作流程运行的事件。 这些事件可以是:
- 工作流程存储库中发生的事件
- 在 GitHub Enterprise Server 之外发生并在 GitHub Enterprise Server 上触发
repository_dispatch
事件的事件 - 预定时间
- 手册
例如,您可以将工作流程配置为在推送到存储库的默认分支、创建发行版或打开议题时运行。
更多信息请参阅“触发工作流程”,有关事件的完整列表,请参阅“触发工作流程的事件”。
工作流程语法
工作流程是使用 YAML 定义的。 有关用于创建工作流程的 YAML 语法的完整参考,请参阅“GitHub Actions 的工作流程语法”。
创建示例工作流程
GitHub Actions 使用 YAML 语法来定义工作流程。 Each workflow is stored as a separate YAML file in your code repository, in a directory named .github/workflows
.
您可以在仓库中创建示例工作流程,只要推送代� �,该工作流程就会自动触发一系列命令。 In this workflow, GitHub Actions checks out the pushed code, installs the bats testing framework, and runs a basic command to output the bats version: bats -v
.
-
在您的仓库中,创建
.github/workflows/
目录来存储工作流程文件。 -
在
.github/workflows/
目录中,创建一个名为learn-github-actions.yml
的新文件并添� 以下代� �。name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: '14' - run: npm install -g bats - run: bats -v
-
提交这些更改并将其推送到您的 GitHub 仓库。
您的新 GitHub Actions 工作流程文件现在安装在您的仓库中,每次有人推送更改到仓库时都会自动运行。 To see the details about a workflow's execution history, see "Viewing the activity for a workflow run."
了解工作流程文件
为帮助您了解如何使用 YAML 语法来创建工作流程文件,本节解释介绍示例的每一行:
|
可选 - 将出现在 GitHub 仓库的 Actions(操作)选项卡中的工作流程名称。 |
|
指定此工作流程的触发器。 此示例使用推送 事件,� 此每次有人将更改推送到存储库或合并拉取请求时,都会触发工作流程运行。 This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for GitHub Actions."
|
|
将 learn-github-actions 工作流程中运行的所有作业组合在一起。
|
|
定义名为 check-bats-version 的作业。 子键将定义作业的属性。
|
|
将作业配置为在最新版本的 Ubuntu Linux 运行器上运行。 这意味着该作业将在 GitHub 托管的新虚拟机上执行。 For syntax examples using other runners, see "Workflow syntax for GitHub Actions." |
|
将 check-bats-version 作业中运行的所有步骤组合在一起。 此部分下嵌套的每项都是一个单独的操作或 shell 脚本。
|
|
uses 关键字指定此步骤将运行 actions/checkout 操作的 v3 。 这是一个将存储库签出到运行器上的操作,允许您对代� �(如生成和测试工具)运行脚本或其他操作。 每当工作流程将针对存储库的代� �运行时,都应使用签出操作。
|
|
此步骤使用 actions/setup-node@v2 操作来安装指定版本的 Node.js(此示例使用 v14)。 这会将 node 和 npm 命令放在 PATH 中。
|
|
run 关键字指示作业在运行器上执行命令。 在这种情况下,使用 npm 来安装 bats 软件测试包。
|
|
最后,您将运行 bats 命令,并且带有输出软件版本的参数。
|
可视化工作流程文件
在此关系图中,您可以看到刚刚创建的工作流程文件,以及 GitHub Actions 组件在层次结构中的组织方式。 每个步骤执行单个操作或 shell 脚本。 步骤 1 和 2 运行操作,步骤 3 和 4 运行 shell 脚本。 要查找更多为工作流预构建的操作,请参阅“查找和自定义操作”。
Viewing the activity for a workflow run
When your workflow is triggered, a workflow run is created that executes the workflow. After a workflow run has started, you can see a visualization graph of the run's progress and view each step's activity on GitHub.
-
在 您的 GitHub Enterprise Server 实例 上,导航到仓库的主页面。
-
在仓库名称下,单击 Actions(操作)。
-
在左侧边� �中,单击您想要查看的工作流程。
-
在“Workflow runs(工作流程运行)”下,单击您想要查看的运行的名称。
-
在 Jobs(作业)下或可视化图中,单击您要查看的作业。
-
View the results of each step.
有关管理工作流程运行(如重新运行、取消或� 除工作流程运行)的详细信息,请参阅“管理工作流程运行”。
使用入门工作流程
GitHub 提供预配置的入门工作流程,您可以自定义以创建自己的持续集成工作流程。 GitHub Enterprise Server 分析代� �并显示可能适用于您的仓库的 CI 模板入门工作流程。 例如,如果仓库包含 Node.js 代� �,您就会看到 Node.js 项目的建议。 您可以使用入门工作流程作为起点来构建自定义工作流程,或按原� �使用工作流程。
您可以在 您的 GitHub Enterprise Server 实例 上的 actions/starter-workflows
仓库中浏览入门工作流程的完整列表。
有关使用和创建入门工作流程的详细信息,请参阅“使用入门工作流程”和“为组织创建入门工作流程”。
高级工作流程功能
本节简介了 GitHub Actions 的一些高级功能,可帮助您创建更复杂的工作流程。
存储密� �
如果您的工作流程使用敏感数据,例如密� �或证书, 您可以将这些信息在 GitHub 中保存为 机密,然后在工作流中将它们用作环境变量。 这意味着您将能够创建和共享工作流程,而� 需直接在工作流程的 YAML 源中嵌入敏感值。
此示例作业演示如何将现有机密引用为环境变量,并将其作为参数发送到示例命令。
jobs:
example-job:
runs-on: ubuntu-latest
steps:
- name: Retrieve secret
env:
super_secret: ${{ secrets.SUPERSECRET }}
run: |
example-command "$super_secret"
更多信息请参阅“� 密密� �”。
创建依赖的作业
默认情况下,工作流程中的作业同时并行运行。 如果您有一个作业必须在另一个作业完成后运行,可以使用 needs
关键字来创建此依赖项。 如果其中一个作业失败,则跳过所有从属作业;但如果您需要作业继续,可以使用条件语句 if
来定义。
在此示例中,setup
、build
和 test
作业连续运行,build
和 test
取决于其前面的作业成功完成:
jobs:
setup:
runs-on: ubuntu-latest
steps:
- run: ./setup_server.sh
build:
needs: setup
runs-on: ubuntu-latest
steps:
- run: ./build_server.sh
test:
needs: build
runs-on: ubuntu-latest
steps:
- run: ./test_server.sh
更多信息请参阅“定义先决条件作业”。
使用矩阵
A matrix strategy lets you use variables in a single job definition to automatically create multiple job runs that are based the combinations of the variables. For example, you can use a matrix strategy to test your code in multiple versions of a language or on multiple operating systems. 矩阵是使用 strategy
关键字创建的,该关键字以数组的形式接收构建选项。 例如,此矩阵将使用不同版本的 Node.js 多次运行作业:
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node: [12, 14, 16]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
更多信息请参阅“对作业使用矩阵”。
使用数据库和服务容器
如果作业需要数据库或缓存服务,可以使用 services
关键字创建临时容器来托管服务;生成的容器然后可用于该作业中的所有步骤,并在作业完成后� 除。 此示例演示作业如何使用 services
创建 postgres
容器,然后使用 node
连接到服务。
jobs:
container-job:
runs-on: ubuntu-latest
container: node:10.18-jessie
services:
postgres:
image: postgres
steps:
- name: Check out repository code
uses: actions/checkout@v2
- name: Install dependencies
run: npm ci
- name: Connect to PostgreSQL
run: node client.js
env:
POSTGRES_HOST: postgres
POSTGRES_PORT: 5432
更多信息请参阅“使用容器化服务”。
使用� �签路由工作流程
如果要确保特定类型的运行器处理作业,可以使用� �签来控制作业的执行位置。 除了 self-hosted
的默认� �签之外,您还可以向自托管运行器分配� �签。 然后,您可以在 YAML 工作流程中引用这些� �签,确保以可预测的方式安排作业。 GitHub 托管的运行器已指定预定义的� �签。
此示例显示工作流程如何使用� �签来指定所需的运行器:
jobs:
example-job:
runs-on: [self-hosted, linux, x64, gpu]
工作流程只能在一个所有� �签处于 runs-on
数组中的运行器上运行。 作业将优先转到具有指定� �签的空闲自托管运行器。
要了解自托管运行器� �签的更多信息,请参阅“将� �签与自托管运行器一起使用”。
使用环境
您可以使用保护规则和机密配置环境,以控制工作流程中作业的执行。 工作流程中的每个作业都可以引用单个环境。 在将引用环境的作业发送到运行器之前,必须通过为环境配置的任何保护规则。 更多信息请参阅“使用环境进行部署”。