概述
我们想要将我们的代码更改集成到托管在 GitHub 上的共享代码库中。到目前为止,我们已经运行了我们的架构检查在本地以确保一切都成功通过。但是,自动执行这些架构检查将更有益,这样我们就不必在每次推送更改时都记得运行它们。
在本课中,我们将
- 了解 架构检查如何融入持续集成 (CI) 管道
- 查看通过 GitHub Actions 自动化的架构检查示例
更新 CI 工作流
我们希望设置 架构检查以针对拉取请求中的代码更改自动运行。这样,每个 PR 在成功合并之前都会检查架构是否仍可正常运行且检查是否通过。我们可以满怀信心地合并,因为知道我们的架构更改不会破坏我们的 超图或现有客户端查询。
以下是 CI 管道中带有 架构检查的更新 CI 工作流的示意图:
创建或更新 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:
部分,该部分概述了为此作业运行哪些命令。
# This job runs a schema check for the staging variantname: Run schema checks# It runs for every PR opened, updated and editedon:pull_request:types: [opened, synchronize, edited]# A workflow run is made up of one or more jobs that can run sequentially or in paralleljobs:schema_checks:name: Run schema checks# The type of runner that the job will run onruns-on: ubuntu-latest# https://githubdocs.cn/en/actions/reference/environmentsenvironment: apollo# https://githubdocs.cn/en/actions/reference/encrypted-secrets# https://githubdocs.cn/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsenvenv:APOLLO_KEY: ${{ secrets.APOLLO_KEY }}APOLLO_VCS_COMMIT: ${{ github.event.pull_request.head.sha }}GRAPH_ID: airlock-managed-fedSUBGRAPH: listings# Steps represent a sequence of tasks that will be executed as part of the jobsteps:# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it- name: Install Roverrun: |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-pathecho "$HOME/.rover/bin" >> $GITHUB_PATH- name: Run check against staging variantrun: |rover subgraph check ${GRAPH_ID}@staging --schema ./${SUBGRAPH}.graphql --name $SUBGRAPH
操作中的自动架构检查
在 GitHub 上准备好这些 CI 作业后,让我们启动我们新的优化工作流!
首先,我们要确保 Listings 团队的代码更改已添加到新分支并已提交到该分支。然后,我们将把这些更改推送到 GitHub。我们将创建一个 PR 来合并到 主干
分支。
当创建该 PR 时,运行架构检查作业会自动触发。我们可以看到作业运行时页面加载和更新。
Lisa 处理的架构添加,架构检查已通过。太棒了!只要在代码审查后一切看起来都不错,我们就可以将更改合并到 主干
分支。
这就是我们的 CI 管道的工作!最后一步是点击我们的 PR 上的 合并,然后触发部署流程。
练习
要点
- 架构检查是强大 CI/CD 管道的重要部分。将架构检查添加到你的管道中,可以在每次有人想对你的代码库做出变更时自动运行检查,这有助于你确信新变更不会破坏内容。
- 我们可以使用与在 CI 自动化中本地使用的
rover 子图检查
命令相同,以执行 架构检查。
接下来
Listings 团队做出的变更已进入我们代码库的 main
分支!让我们继续进行 CD 工作流以部署这些变更。
分享你对本课程的问题和评论
您的反馈将帮助我们改进!如果你遇到了阻碍或者困惑,请告知我们,我们会帮到你。所有评论都是公开的,并且必须遵循 Apollo 行为准则。请注意,已解决或已处理的评论可能会被移除。
您需要一个 GitHub 账户才能发布您的评论。没有吗? 改用我们的 Odyssey 论坛来发帖。