Requiring Successful CircleCI builds Before Merging GitHub Pull Requests

Rocky Top Solutions
Sep 22 · 4 min read

You are a software developer and/or a project manager and you and your team want to make sure that new code changes won’t break your project in any way before you push the changes to production. Great! Well, how do we go about making sure that we do everything we can to make sure that doesn’t happen?


One great thing to add to you workflow in order to help with this is to require successful builds with the new code before merging into your staging and production branches in your source code repository. If you are using GitHub to host your source code and CircleCI to run your automated builds, I am going to lay out how you can leverage the GitHub’s status API to block pull requests if new code breaks your builds.


First thing we need to setup is GitHub. If you don’t already have a repository setup in GitHub, do that first thing. Next, you’ll want to head over to CircleCI and sign in with GitHub allowing access to whichever repos you want to use with CircleCI. Once you are logged in to CircleCI, you should see a screen similar to the following:

Next, click Set Up Project next to the repository you wish to setup automated builds with. This will show a menu of the different default programming languages that CircleCI integrates with and has default images for. It will look like the following:

Select your desired programming language, which will then show a default base configuration file for that particular language. For example, if you select Node as your desired programing language, it will show you a default CircleCI configuration file that resembles the following:

# Javascript Node CircleCI 2.0 configuration file
#
# Check https://circleci.com/docs/2.0/language-javascript/ for more details
#
version: 2
jobs:
build:
docker:
# specify the version you desire here
- image: circleci/node:7.10

# Specify service dependencies here if necessary
# CircleCI maintains a library of pre-built images
# documented at https://circleci.com/docs/2.0/circleci-images/
# - image: circleci/mongo:3.4.4

working_directory: ~/repo

steps:
- checkout

# Download and cache dependencies
- restore_cache:
keys:
- v1-dependencies-{{ checksum "package.json" }}
# fallback to using the latest cache if no exact match is found
- v1-dependencies-

- run: yarn install

- save_cache:
paths:
- node_modules
key: v1-dependencies-{{ checksum "package.json" }}
# run tests!
- run: yarn test

In your repository on GitHub, create a file .circleci/config.yml in your master (or current default)branch and paste the example config file into that file. After you have done that, go back to CircleCI and in the setup screen where you copied the default config file from, click the button Start Building. If your first build fails, it may be because you don’t have any unit tests setup yet. You can remove the - run: yarn test line and replace it with — run: echo "Hello World" in order just to get the build passing.


After getting your first successful build on CircleCI, we need to go back to GitHub and go to your repo, then click Settings in top menu list > Branches in left menu list. Next to Branch Protection Rules, click Add Rule. This will bring up a screen that looks like the following:

As you can see from the above photo, you will need to select Require status checks to pass before merging option. This is what we need in order to block any PR’s from being merged if our automated builds fail with new changes. If you also want to make sure the new changes being merged aren’t missing any code that has been pushed since the current changes have been checked out, you’ll also want to select Require branches to be up to date before merging. As you can also see, you will need to select ci/circleci: build to be one of the statuses that has to be successful before merging. You can also add the same checks to other branches as long as the CircleCI config file has been added to those branches and a successful run has been completed in CircleCI.


After applying these changes to GitHub, any future pull requests for the repository and for the specified branch(es). This should help you keep many of the errors from reaching your production workload since your unit tests, E2E tests, and all other checks ran in CI/CD pipelines should catch most of them before it can be merged into your production branch(es).

Software Development Tutorials

Tutorials on the different aspects of software development workflow

Rocky Top Solutions

Written by

Service Disabled Veteran Owned Small Business providing custom website and mobile app development services, SEO services, and technology consulting.

Software Development Tutorials

Tutorials on the different aspects of software development workflow

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade