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 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 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://docs.github.com/en/actions/reference/environmentsenvironment: apollo# https://docs.github.com/en/actions/reference/encrypted-secrets# https://docs.github.com/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- uses: actions/checkout@v4.1.5- 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://docs.github.com/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
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.
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.
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.
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.
Practice
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.