Skip to main content

Understanding GitHub Actions

Learn the basics of GitHub Actions, including core concepts and essential terminology.


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 的组件

You can configure a GitHub Actions workflow to be triggered when an event occurs in your repository, such as a pull request being opened or an issue being created. Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.



A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

Your repository can have multiple workflows in a repository, each of which can perform a different set of steps. For example, you can have one workflow to build and test pull requests, another workflow to deploy your application every time a release is created, and still another workflow that adds a label every time someone opens a new issue.

For more information about workflows, see "Using workflows."


An event is a specific activity in a repository that triggers a workflow run. For example, activity can originate from GitHub when someone creates a pull request, opens an issue, or pushes a commit to a repository. You can also trigger a workflow run on a schedule, by posting to a REST API, or manually.



A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run. Steps are executed in order and are dependent on each other. Since each step is executed on the same runner, you can share data from one step to another. For example, you can have a step that builds your application followed by a step that tests the application that was built.

You can configure a job's dependencies with other jobs; by default, jobs have no dependencies and run in parallel with each other. When a job takes a dependency on another job, it will wait for the dependent job to complete before it can run. For example, you may have multiple build jobs for different architectures that have no dependencies, and a packaging job that is dependent on those jobs. The build jobs will run in parallel, and when they have all completed successfully, the packaging job will run.

For more information about jobs, see "Using jobs."


An action is a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. Use an action to help reduce the amount of repetitive code that you write in your workflow files. An action can pull your git repository from GitHub, set up the correct toolchain for your build environment, or set up the authentication to your cloud provider.

You can write your own actions, or you can find actions to use in your workflows in the GitHub Marketplace.



A runner is a server that runs your workflows when they're triggered. Each runner can run a single job at a time. You must host your own runners for GitHub AE. For more information, see "Hosting your own runners."


GitHub Actions uses YAML syntax to define the workflow. Each workflow is stored as a separate YAML file in your code repository, in a directory called .github/workflows.

您可以在仓库中创建示例工作流程,只要推送代码,该工作流程就会自动触发一系列命令。 在此工作流程中,GitHub Actions 检出推送的代码,安装软件依赖项,并运行 -v

  1. 在您的仓库中,创建 .github/workflows/ 目录来存储工作流程文件。
  2. .github/workflows/ 目录中,创建一个名为 learn-github-actions.yml 的新文件并添加以下代码。
    name: learn-github-actions
    on: [push]
        runs-on: ubuntu-latest
          - uses: actions/checkout@v2
          - uses: actions/setup-node@v2
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
  3. 提交这些更改并将其推送到您的 GitHub 仓库。

您的新 GitHub Actions 工作流程文件现在安装在您的仓库中,每次有人推送更改到仓库时都会自动运行。 有关作业的执行历史记录的详细信息,请参阅“查看工作流程的活动”。


为帮助您了解如何使用 YAML 语法来创建工作流程文件,本节解释介绍示例的每一行:

name: learn-github-actions
可选 - 将出现在 GitHub 仓库的 Actions(操作)选项卡中的工作流程名称。
on: [push]
Specifies the trigger for this workflow. This example uses the push event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request. 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."
Groups together all the jobs that run in the learn-github-actions workflow.
Defines a job named check-bats-version. The child keys will define properties of the job.
  runs-on: ubuntu-latest
Configures the job to run on the latest version of an Ubuntu Linux runner. 这意味着该作业将在 GitHub 托管的新虚拟机上执行。 有关使用其他运行器的语法示例,请参阅“GitHub Actions 的工作流程语法”
check-bats-version 作业中运行的所有步骤组合在一起。 Each item nested under this section is a separate action or shell script.
    - uses: actions/checkout@v2
The uses keyword specifies that this step will run v2 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will run against the repository's code.
    - uses: actions/setup-node@v2
        node-version: '14'
This step uses the actions/setup-node@v2 action to install the specified version of the Node.js (this example uses v14). This puts both the node and npm commands in your PATH.
    - run: npm install -g bats
run 关键字指示作业在运行器上执行命令。 在这种情况下,使用 npm 来安装 bats 软件测试包。
    - run: bats -v
最后,您将运行 bats 命令,并且带有输出软件版本的参数。


在此关系图中,您可以看到刚刚创建的工作流程文件,以及 GitHub Actions 组件在层次结构中的组织方式。 Each step executes a single action or shell script. Steps 1 and 2 run actions, while steps 3 and 4 run shell scripts. 要查找更多为工作流预构建的操作,请参阅“查找和自定义操作”。


Viewing the workflow's activity

Once your workflow has started running, you can see a visualization graph of the run's progress and view each step's activity on GitHub.

  1. 在 your enterprise 上,导航到仓库的主页面。

  2. 在仓库名称下,单击 Actions(操作)导航到仓库

  3. 在左侧边栏中,单击您想要查看的工作流程。 工作流程结果的屏幕截图

  4. 在“Workflow runs(工作流程运行)”下,单击您想要查看的运行的名称。 工作流程运行的屏幕截图

  5. Jobs(作业)下或可视化图中,单击您要查看的作业。 选择作业

  6. 查看每个步骤的结果。 工作流程运行详细信息的屏幕截图


要继续了解 GitHub Actions,请参阅“查找和自定义操作”。


如果需要任何与工作流程配置相关的帮助,比如语法、GitHub 托管的运行器或构建操作,请在 GitHub Community Support 的 GitHub Actions 类别中查找现有主题或发起一个新主题。

如果您有对 GitHub Actions 的反馈或功能请求,请在 GitHub 操作的反馈表 中分享。

如有以下任意情况,无论您的使用或预期使用是否属于使用限制类别,都请联系 your enterprise owner:

  • 如果您认为您的帐户受到不正确的限制
  • 如果您在执行您的操作之一时遇到意外错误,例如:唯一的 ID
  • 如果你遇到与预期矛盾现有行为,但不一定是文件记录的情况。