Schema checks in CI

6. Schema checks in CI

Overview

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:

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.

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://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
    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/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.

https://github.com

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.

https://github.com

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.

https://github.com

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.

Practice

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

Schema checks catch potential breaking changes before they make it into your codebase.Teammates don't have to review pull requests at all.Schema checks can be automated, reducing human error when forgetting to run checks locally.

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.

Share your questions and comments about this lesson

Your feedback helps us improve! If you're stuck or confused, let us know and we'll help you out. All comments are public and must follow the Apollo Code of Conduct. Note that comments that have been resolved or addressed may be removed.

You'll need a GitHub account to post below. Don't have one? Post in our Odyssey forum instead.