6. Schema checks in CI


We want to integrate our code changes into the shared codebase hosted on GitHub. So far, we've run our schema checks locally to make sure everything passes successfully. But it would be much more beneficial to automate those schema checks, so that we don't have to remember to run them every time we push a change.

In this lesson, we will:

  • Learn how schema checks fit into the continuous integration (CI) pipeline
  • View an example of a schema check automated through GitHub Actions

Updating the CI workflow

We want to set up schema checks to run automatically against the code changes in a pull request. This way, every PR will check that the schema still works and checks are passing before it can be successfully merged. We can merge with confidence, knowing that our schema changes won't break our supergraph or existing client queries.

Here's a diagram of the updated CI workflow with schema checks in the CI pipeline:

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

Creating or updating a pull request triggers schema checks to run.

If the checks fail, we'll see the errors in the GitHub PR, which will also link to Apollo Studio for more details. We'll need to investigate the error, fix it in our local environment and follow the process again from the start. We'll take a look at some examples of errors later on.

If the checks pass, great! We can merge the changes to the main branch. This automatically triggers the CD workflow, which we'll talk about in the next lesson.

Adding schema checks in the CI workflow

There are many different tools you could use to set up the CI process. Airlock uses GitHub Actions.

Tip: In this course, we're only focused on using GitHub Actions to run schema checks. But you could use them to add other scripts too, like automated tests or lint checks. For more information, refer to the GitHub Actions documentation.

Each of the Airlock subgraph repositories on GitHub already has a suite of GitHub Actions set up to run a job every time a pull request is created or updated. One of those GitHub Actions sets up schema checks to run against the staging variant of our graph. Behind the scenes, this job uses the same rover subgraph check command we saw before!

Note: Don't worry too much about the specific syntax for these GitHub Actions. The goal of this course is more about getting a big-picture sense of how all the pieces of deployment fit together. Pay attention to the steps: section, which outlines what commands to run for this job.

# This job runs a schema check for the staging variant
name: Run schema checks
# It runs for every PR opened, updated and edited
types: [opened, synchronize, edited]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
name: Run schema checks
# The type of runner that the job will run on
runs-on: ubuntu-latest
# https://docs.github.com/en/actions/reference/environments
environment: apollo
# https://docs.github.com/en/actions/reference/encrypted-secrets
# https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsenv
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
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- 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://docs.github.com/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

Automatic schema check in action

With those CI jobs ready to go on GitHub, let's kick off our new and improved workflow!

First we'll make sure the code changes from the Listings team are added and committed to a new branch. Then we'll push those changes up to GitHub. We'll create a PR to merge to the main branch.

Screenshot of GitHub, creating a pull request.

When that PR is created, the Run schema checks job is triggered automatically. We can see the page loading and updating as the job runs.

Screenshot of GitHub PR showing schema checks loading

For the schema additions that Lisa worked on, schema checks passed. Awesome! Provided everything looks good after a code review, we can merge the changes into the main branch.

Screenshot of GitHub PR showing passing checks

And that's it for our CI pipeline! The last step would be to click Merge on our PR, which then triggers the deployment process.

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


Which of the following are benefits of adding schema checks to the CI pipeline?

Key takeaways

  • Schema checks are an essential part of a robust CI/CD pipeline. Adding schema checks to your pipeline lets you automatically run them every time someone wants to make changes to your codebase, which helps you gain confidence that new changes won't break things.
  • We can use the same rover subgraph check command that we used locally in our CI automation to perform schema checks.

Up next

The changes from the Listings team have made their way to the main branch of our codebase! Let's move on to our CD workflow to deploy those changes.