6. CI 中的架构检查
5m

概述

我们想要将我们的代码更改集成到托管在 GitHub 上的共享代码库中。到目前为止,我们已经运行了我们的在本地以确保一切都成功通过。但是,自动执行这些架构检查将更有益,这样我们就不必在每次推送更改时都记得运行它们。

在本课中,我们将

  • 了解 如何融入持续集成 (CI) 管道
  • 查看通过 GitHub Actions 自动化的架构检查示例

更新 CI 工作流

我们希望设置 以针对拉取请求中的代码更改自动运行。这样,每个 PR 在成功合并之前都会检查架构是否仍可正常运行且检查是否通过。我们可以满怀信心地合并,因为知道我们的架构更改不会破坏我们的 或现有客户端查询。

以下是 CI 管道中带有 的更新 CI 工作流的示意图:

Diagram of CI workflow - schema checks in CI added. See detailed image description below.

创建或更新 Pull Request 会触发 运行。

如果检查失败,我们将在 GitHub PR 中看到错误,同时也会链接到 Studio 以便了解更多详情。我们需要调查错误,在我们的 local环境中修复错误,并从头再次执行此流程。我们稍后会了解一些错误示例。

如果检查通过,太好了!我们可以将更改合并到 main分支。这会自动触发 CD 工作流,我们将在下一课中讨论该工作流。

在 CI 工作流中添加架构检查

您可以使用许多不同的工具来设置 CI 流程。Airlock 使用 GitHub Actions。

提示:在本课程中,我们只关注使用 GitHub Actions 运行 。但是,您也可以使用它们来添加其他脚本,例如自动测试或 lint 检查。有关详细信息,请参阅 GitHub Actions 文档

GitHub 上的每个 Airlock 存储库都已设置了一套 GitHub 操作,以便在每次创建或更新合并请求时运行作业。其中一个 GitHub 操作设置了 以针对 过渡准备 运行,即我们的 。在后台,此作业使用我们之前看到的相同的 rover 子图检查命令!

注意:不必太担心这些 GitHub 操作的特定语法。本课程的目标主要是让你对部署的所有部分如何衔接在一起有一个全面的了解。请注意 steps:部分,该部分概述了为此作业运行哪些命令。

subgraph-accounts/.github/workflows/check.yml
# This job runs a schema check for the staging variant
name: Run schema checks
# It runs for every PR opened, updated and edited
on:
pull_request:
types: [opened, synchronize, edited]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
schema_checks:
name: Run schema checks
# The type of runner that the job will run on
runs-on: ubuntu-latest
# https://githubdocs.cn/en/actions/reference/environments
environment: apollo
# https://githubdocs.cn/en/actions/reference/encrypted-secrets
# https://githubdocs.cn/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsenv
env:
APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}
GRAPH_ID: airlock-managed-fed
SUBGRAPH: listings
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/[email protected]
- name: Install Rover
run: |
curl -sSL https://rover.apollo.dev/nix/latest | sh
# Add Rover to the $GITHUB_PATH so it can be used in another step
# https://githubdocs.cn/en/actions/reference/workflow-commands-for-github-actions#adding-a-system-path
echo "$HOME/.rover/bin" >> $GITHUB_PATH
- name: Run check against staging variant
run: |
rover subgraph check ${GRAPH_ID}@staging --schema ./${SUBGRAPH}.graphql --name $SUBGRAPH

操作中的自动架构检查

在 GitHub 上准备好这些 CI 作业后,让我们启动我们新的优化工作流!

首先,我们要确保 Listings 团队的代码更改已添加到新分支并已提交到该分支。然后,我们将把这些更改推送到 GitHub。我们将创建一个 PR 来合并到 主干分支。

https://github.com
Screenshot of GitHub, creating a pull request.

当创建该 PR 时,运行架构检查作业会自动触发。我们可以看到作业运行时页面加载和更新。

https://github.com
Screenshot of GitHub PR showing schema checks loading

Lisa 处理的架构添加,已通过。太棒了!只要在代码审查后一切看起来都不错,我们就可以将更改合并到 主干分支。

https://github.com
Screenshot of GitHub PR showing passing checks

这就是我们的 CI 管道的工作!最后一步是点击我们的 PR 上的 合并,然后触发部署流程。

Diagram of full CI workflow with schema checks included. See below for a detailed image description.

练习

在 CI 管道中添加架构检查有什么好处?

要点

  • 是强大 CI/CD 管道的重要部分。将架构检查添加到你的管道中,可以在每次有人想对你的代码库做出变更时自动运行检查,这有助于你确信新变更不会破坏内容。
  • 我们可以使用与在 CI 自动化中本地使用的 rover 子图检查 命令相同,以执行

接下来

Listings 团队做出的变更已进入我们代码库的 main 分支!让我们继续进行 CD 工作流以部署这些变更。

上一页

分享你对本课程的问题和评论

您的反馈将帮助我们改进!如果你遇到了阻碍或者困惑,请告知我们,我们会帮到你。所有评论都是公开的,并且必须遵循 Apollo 行为准则。请注意,已解决或已处理的评论可能会被移除。

您需要一个 GitHub 账户才能发布您的评论。没有吗? 改用我们的 Odyssey 论坛来发帖。