登录
返回训练营在 GitHub 上查看

使用 Actions 进行测试

创建工作流，让你的项目具备持续集成（CI）能力。

这是一个交互式课程，需要在 GitHub 上实际操作来完成学习。本页面为静态预览，仅方便您一次性阅读所有步骤内容。

前往 GitHub 开始学习 →

📖课程概览

使用 Actions 进行测试

创建工作流，让你的项目具备持续集成（CI）能力。

Welcome

持续集成（Continuous Integration，简称CI） 可以帮助你和团队在开发过程中保持良好的代码质量。 它会在每次提交后自动运行构建与测试，并在 GitHub 上反馈结果。这样能让主分支（main）的问题更少，开发过程中的反馈也更及时。

  • 目标人群：开发者、DevOps 工程师、GitHub 新用户、学生、团队。
  • 学习内容：了解持续集成的概念、学习如何使用 GitHub Actions 实现 CI、掌握创建运行测试并生成测试报告的工作流。
  • 您将完成：我们将使用 remark-lint 来检查 Markdown 文件的格式一致性。
  • 先决条件：建议先完成 Hello GitHub Actions 课程。
  • 学习时长：整个课程用时不到两小时。

在这门课程中，你将完成以下任务：

  1. 添加一个用于测试的工作流(Workflow)
  2. 修复测试中发现的问题
  3. 上传测试报告
  4. 设置分支保护
  5. 合并你的拉取请求（Pull Request）

如何开始课程

start-course

  1. 右键点击上方 Start course 按钮，选择在新标签页中打开链接。
  2. 在新页面中根据系统提示新建一个仓库。
    • 仓库名称、描述这些字段系统已经帮我们自动填充好了，您可以按需修改。
    • 建议选择公开仓库，因为私有仓库有GitHub Actions 分钟数限制。
    • 最后点击 Create repository 按钮
  3. 仓库创建完毕后，等待大约 20 秒（等待Action执行），然后刷新页面。注意是刷新您仓库的页面，不是本课程的页面。如果页面没有变化，请继续等待。然后按照 README 中的步骤一步步进行。

🎯课程步骤

GitHub

Step 1: 添加测试工作流

欢迎来到 "GitHub Actions: 持续集成" 课程! 👋

什么是 持续集成(CI)?: Continuous integration 它能帮助你在团队开发中保持良好的代码质量。每次提交（commit）都会触发自动构建和测试，测试结果会反馈到 GitHub 的拉取请求（Pull Request）中。这样既能减少 main 分支中的问题，又能让你在开发时获得更快的反馈。

An illustration with a left half and a right half. On the left: illustration of how GitHub Actions terms are encapsulated. At the highest level: workflows and event triggers. Inside workflows: jobs and definition of the build environment. Inside jobs: steps. Inside steps: a call to an action. On the right: the evaluated sequence: workflow, job, step, action.

  • Workflow（工作流）：从触发到结束的一整套自动化流程。包括触发条件、运行环境以及触发后执行的任务。
  • Job（任务）：工作流中的一个阶段，由一个或多个步骤组成。例如，这里我们定义的 build 任务就是其中一部分。
  • Step（步骤）：任务中的一个具体动作，比如运行某个命令或执行一个 Action。
  • Action（动作）：一个可复用的自动化单元，可以由 GitHub 官方、开源社区，或者你自己编写。

想了解更多，请查看 GitHub 文档：Workflow syntax for GitHub Actions。

接下来，我们要在这个仓库中添加一个工作流，用来检测（lint）Markdown 文件的格式一致性。

⌨️ 实操环节: 添加测试工作流

  1. 打开一个新的浏览器标签页，方便一边操作一边阅读本教程。

  2. 进入仓库的 Actions tab页。

  3. 点击 New workflow（新建工作流）。

  4. 搜索 “Simple workflow”，并点击 Configure（配置）。

  5. 将工作流文件命名为 ci.yml。

  6. 删除模板中最后两个步骤。

  7. 在工作流的末尾添加以下步骤：

    - name: Run markdown lint
  run: |
    npm install remark-cli remark-preset-lint-consistent
    npx remark . --use remark-preset-lint-consistent --frail

    即使在 ci.yml 中正确缩进后，GitHub Actions 仍可能报错。我们会在下一步修复它。

  8. 点击 Commit changes...（提交更改），并选择创建一个名为 ci 的新分支。

  9. 点击 Propose changes（提交修改建议）。

  10. 点击 Create pull request（创建拉取请求）。

  11. 等待大约 20 秒，然后刷新此页面（即当前教程页面）。GitHub Actions 会自动检测并跳转到下一步。

GitHub

Step 2: 修复测试问题

做得好！你已经成功添加了模板工作流! 🎉*

把这个文件添加到分支中后，GitHub Actions 就会自动在你的仓库上运行持续集成（CI）流程。

当 GitHub Actions 开始执行工作流时，你会在拉取请求的合并区域看到类似下图的检查进度：

checks in progress in a merge box

你可以通过进入 Actions 标签页，或者点击合并区域中的 Details（详细信息），来查看 GitHub Actions 的执行情况。

测试完成后，你会看到一个红色叉号 ❌（代表失败）或 ✔️（代表通过）。这时，你可以打开构建日志，查看每个步骤的执行结果。

能从日志中看出是哪个测试没通过吗？ 进入一个失败的构建，向下滚动日志，找到列出所有单元测试的部分。带有 “x” 的那一项就是出错的测试。

screenshot of a sample build log with the names of the tests blurred out

如果没有出现检查结果，或者检查卡在“运行中”状态，可以尝试以下方法让它重新触发：

  • 刷新页面，有时工作流已运行完，但页面尚未更新。
  • 在当前分支上再提交一次，因为工作流是通过 push 事件触发的。
  • 打开 GitHub 上的工作流文件，确认没有红色波浪线提示语法错误。

⌨️ 实操环节：修复测试问题

  1. 修改 ci 分支中的内容，为了让测试能够通过。你需要查看日志来找出失败的原因。
  2. 提交更改（Commit changes）。
  3. 等待大约 20 秒，然后刷新此页面（当前教程页面）。GitHub Actions 会自动检测并跳转到下一步。
GitHub

Step 3: 上传测试报告

工作流已经运行完成啦! 🎉

那如果我们想在另一个任务（job）中使用上一个任务的输出结果，该怎么办呢？ 可以借助 GitHub Actions 内置的 artifact 存储功能，把某个任务生成的文件保存下来，供同一个工作流中的其他任务使用。

要上传这些文件（称为“构件”或 artifact），我们可以使用 GitHub 官方提供的 actions/upload-artifact 这个 Action。

⌨️ 实操环节: 上传测试报告

  1. 打开并编辑你的工作流文件。

  2. 在 build 任务中的 Run markdown lint 步骤里，修改命令，使用 vfile-reporter-json 把检测结果输出为 remark-lint-report.json。

  3. 在 build 任务中添加一个新步骤，使用 upload-artifact 动作，把生成的 remark-lint-report.json 文件上传到 artifact 存储中。

  4. 修改后的 build 任务应如下所示：

    build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Run markdown lint
      run: |
        npm install remark-cli remark-preset-lint-consistent vfile-reporter-json
        npx remark . --use remark-preset-lint-consistent --report vfile-reporter-json 2> remark-lint-report.json

    - uses: actions/upload-artifact@v4
      with:
        name: remark-lint-report
        path: remark-lint-report.json

  5. 提交（Commit）修改到当前分支。

  6. 等待大约 20 秒，然后刷新本教程页面。GitHub Actions 会自动检测更新并进入下一步。

就像 upload-artifact 负责上传文件一样，你也可以使用 actions/download-artifact 在后续任务中下载这些文件。 不过，为了让课程流程更简洁，这里我们暂时不演示下载步骤。

GitHub

Step 4: 添加分支保护规则

太棒了! 你已经成功上传了测试报告! 🥳

现在看看拉取请求的合并区域，你会发现：即使没有经过代码审查（review），这个分支仍然可以被合并。

为了避免这种情况，我们可以启用“分支保护”（Protected Branches）。 分支保护能防止协作者直接对关键分支进行不可逆的修改，还可以开启一系列额外的限制，比如：

  • 必须通过状态检查（Status Checks）才能合并
  • 必须经过代码审查（Review）
  • 禁止强制推送（Force Push）等

通过这些设置，可以更好地保护 main 分支的稳定性和代码质量。

⌨️ 实操环节: 添加分支保护

  1. 打开仓库的 Branches（分支） 设置页面。你可以在仓库顶部最右侧点击 Settings（设置） 标签，然后在左侧菜单中点击 Branches。
  2. 在 “Branch protection rules” 区域下，点击 Add classic branch protection rule（添加经典分支保护规则）。
  3. 在 Branch name pattern（分支名称模式） 中输入 main。
  4. 勾选 Require a pull request before merging（合并前需要拉取请求）。
  5. 取消勾选 Require approvals（需要审批）。
  6. 勾选 Require status checks to pass before merging（合并前必须通过状态检查）。
  7. 在出现的灰色区域中，勾选所有你希望强制通过的构建与测试任务。
  8. 点击 Create（创建） 保存规则。
  9. 一旦启用了分支保护，GitHub Actions 将不能再直接向 main 分支推送代码。等待大约 20 秒后，切换到 ci 分支。GitHub Actions 会自动检测到更改，并在 ci 分支中进入下一步。
GitHub

Step 5: 合并你的拉取请求

离完成只差最后一步啦! ❤️

现在，你可以合并 你的PR!

⌨️ 实操环节

  1. 进入 Pull requests tab页。
  2. 点击 Merge pull request（合并拉取请求） 按钮。
  3. 启用分支保护后，GitHub Actions 将无法直接向 main 分支推送代码。 请确保你当前是在 ci 分支上执行合并操作。
  4. 等待大约 20 秒，然后刷新此页面。GitHub Actions 会自动检测到更新并进入下一步。
GitHub

完成

🎉恭喜你已经完成了本课程！

celebrate

以下是课程回顾：

  • 我们创建了一个 Actions 工作流，用于检查（lint）Markdown 文件。
  • 你发现了文件中的问题，并在它进入 main 分支之前修复了它。
  • 你学习了如何使用构建产物（build artifacts）来保存测试报告。
  • 你启用了分支保护，确保在合并前工作流必须通过。

接下来可以做什么？

步骤导航

关于 GitHub Skills

GitHub Skills 是 GitHub 官方提供的交互式学习平台。 原始课程需要在 GitHub 上执行操作，通过 GitHub Actions 自动检测进度。

本页面将所有步骤展示在一个页面中，方便您一次性阅读全部内容。

前往 GitHub 实操练习