Home » circleci
Tag:

circleci

GitHub Actions vs CircleCI logos image
GeneralTechnology Comparisons

Which is Better? GitHub Actions vs Circle CI

by corey.walker
written by corey.walker 9 minutes read

In earlier posts, I have compared Travis CI vs Circle CI, Travis CI vs Jenkins, and Circle CI vs Jenkins. In this article, I’ll be including what is arguably the most popular newcomer to the group of CI/CD service providers. Do you know which is better for your needs?

One of the newest platforms to offer the CI/CD pipeline space is GitHub Actions. Another option that has been around for a few years now and is a great candidate for any CI/CD pipelines is Circle CI. Circle CI is one of the most popular cloud-based CI/CD pipeline providers available today. In this post, I will compare the two platforms and lay out the differences between each, and provide a list of what I believe are the pros and cons of each. Let’s get started!

Check out our related YouTube video:

YouTube Thumbnail – GitHub Actions vs Circle CI

GitHub Actions

This is an awesome new player in the CI/CD pipeline space provided by GitHub. They have been around for a long time and are also the most popular SCM provider in the world. GitHub offers great features and a great user experience for their SCM offerings. 

GitHub Actions recently joined in the CI/CD pipeline space back in November 2019. It was an instant hit among many companies and people that already used the platform. This allowed for easier integration with code already hosted on GitHub, as well as the option to reduce the number of services you need to subscribe to or purchase to have a complete CI/CD workflow. This is obviously a great feature regarding GitHub Actions. It also allows for much easier viewing of the pipeline status for each build since you do not have to leave GitHub’s website to see any logs and/or errors; the tab is right there as part of your repository’s UI. 

Screenshot of GitHub Actions tab in GitHub web UI

Features

You can utilize containers or VMs in your builds and you can also use GitHub Actions to run on GitHub or on-prem.

Use your own VMs, in the cloud or on-prem, with self-hosted runners.

GitHub Actions also has support for the most popular programming languages today. These include Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET, and more. Just like Circle CI, GitHub Actions is also available to build on Linux, macOS, and Windows. However, Circle CI does have a couple of extra options for building images/OS compared to GitHub Actions. 

Another great feature of GitHub Actions is the catalog of community-provided Actions you can add to your workflow without re-inventing the wheel. Don’t waste your precious time doing something that someone else has already done! Wondering if someone has already created the action you need in your workflow? Check out the catalog of available Actions here.

The build matrix is another great feature that GitHub Actions has but Circle CI lacks. This allows you to run multiple builds or tests simultaneously using different language versions, platform versions, etc. This can save quite a bit of time and also allow you to see if any certain language versions or platforms break with your new changes. For more information on creating a build matrix and what it can help with, check out this article.

Configuration

The configuration of GitHub Actions is very similar to that of Circle CI. You create a .github/workflows directory and create YAML files inside that directory. You can create different YAML files for each job or add them all to a single file if you wish. For a full list of available references, you can add to your GitHub Actions config files, check out the reference guide. For a simple example of how to set up a GitHub Actions configuration file, check out our example repo here.

Pricing

The pricing structure is similar to that of Circle CI. You pay for the amount of time your CI/CD pipelines are running per billing period. They also have a free tier that can be used indefinitely without any cost as long as you stay below the threshold for the free tier. GitHub Actions gives ~2K action minutes per month for free. 

Circle CI

Circle CI is one of the most popular cloud-hosted CI/CD providers. It was founded in 2011 and is based in San Francisco, CA. Circle CI is among the most popular CI/CD platforms for open source projects. It has support for a variety of languages with multiple pricing plans available to suit most peoples’ needs. Circle CI currently, as of this writing, is only available for repositories hosted on GitHub and BitBucket.

Configuration

You can configure Circle CI easily by just creating a file in the root of your SCM repo called .circleci/config.yml. You can find details on how to configure this file and all the available options here. This allows for the ability to copy the configuration file to multiple repositories and just edit the relevant details specific to that repo and everything will work. S

Some CI/CD tools require setting up the process manually to start with, and each time you create another project, you have to go through those same steps to set it up each time. Some steps could be overlooked or missed from time to time, which is not ideal. This can cause some of your automated processes to not work correctly, and thus possibly cause issues down the road if it goes unnoticed. You can find steps to set up Circle CI with GitHub here. You can find steps to set up Circle CI with BitBucket here.

Pricing

Circle CI is always free for open-source projects. For projects with private repositories, Circle CI has a free plan that has limited “credits” per week (as of this writing, it is 2500/week). For the default medium size Docker build container, that would give you about 250 minutes a week in build time since the medium docker image build container uses 10 credits per minute. You can use this free plan forever if your projects are not constantly running builds. If your projects only need a few builds a week, this is a great option! 

Below is a screenshot listing the majority of build container options available as of this writing and the number of credits per minute each one uses. One advantage Circle CI has over GitHub Actions is the GPU is they had GPU enhanced build option types. If your builds require the heavy lifting of GPU builds, these are a great option to have. 

Chart of credits used for different machine types
Chart of credits used for different machine types
Chart of credits used for different machine types
Chart of credits used for different machine types – Part 2

Beyond the free starter plan, Circle CI pricing is based on what they call “credits”. They do not have a paid plan that offers unlimited builds. This is something to keep in mind if you have many projects that are running builds on a consistent basis as this could spike the costs for your team if you do not estimate correctly. The paid plan starts at $30/month. You can find all pricing details for Circle CI here.

Supported Languages

Circle CI supports many of today’s most popular programming languages which can be found here.

Pros and Cons

GitHub Actions Pros

  • One interface for both your source code repositories and your CI/CD pipelines
  • Only 1 bill to pay that includes both your SCM plan and your CI/CD service (if you pay for either now that is)
  • Option to create a Build Matrix
  • You get around 2x the amount of build time per month on the free tier compared to Circle CI (2500 for GA and 1000 for Circle CI based on default configurations)
  • Catalog of available Actions you can utilize without reinventing the wheel

GitHub Actions Cons

  • Newer platform. Thus not as quite many features as Circle CI as of yet (although they sure have had a strong start)
  • Only available for project repositories hosted on GitHub or GitHub Enterprise
  • Does not have GPU-enhanced build options

Circle CI Pros

  • They have GPU-enhanced build options for projects needing the extra boot from GPU builds
  • Has a free tier (although not as many free build minutes as GitHub Actions)
  • More widely used than GitHub Actions (as of this writing) and thus more community-based support
  • Can be hooked up to more SCMs than just GitHub or GitHub Enterprise

Circle CI Cons

  • Not as many minutes on the free tier as GitHub Actions
  • Not as many available plugins to help ease the configuration of actions others have already completed
  • Need multiple subscriptions for both SCM and CI/CD services
  • Switching back and forth between Circle CI and SCM to see build logs and errors

Conclusion

The best platform for you all depends on your specific needs. If you host your code somewhere other than GitHub.com or GitHub Enterprise, you will be better off using Circle CI. However, if you host your code on GitHub.com or GitHub Enterprise, the choice can be a little more difficult. 

For most people, if they have a small number of projects whose CI/CD config files are relatively simple, I would suggest moving over to try GitHub Actions. Don’t disconnect or delete your current pipelines until you try GA out for a project or two, however. Just add the config files in for GA and see how you like the flow and feel of it. Once you verify that GA has everything you need to do your builds properly and successfully, and they have been running for at least a week or two successfully, you can delete your other config files and cancel your previous CI/CD service.

If you have complex projects or projects that need the hefty boost of GPU builds, I would suggest trying out or sticking with Circle CI. They have a few more options to help with more complex build scenarios since they are the mature CI/CD service provider. 

Go check out my posts comparing Travis CI vs Circle CI, Travis CI vs Jenkins, and Circle CI vs Jenkins to learn about other CI/CD platforms and the differences between them.

Please let me know which platform you think is better or that you prefer using and why in the comments!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail
CircleCI Getting Started Image
Tutorials

How To Use Circle CI – Getting Started With CI/CD

by corey.walker
written by corey.walker 6 minutes read

Are you looking for a better way to manage your software development workflow? Tired of doing so many things manually or want to make sure bugs don’t get in the final product? That’s where DevOps comes into play! In this post, we will learn how to use Circle CI to improve our software development workflow!

Check out our related YouTube video below:

Creating an Account

The first thing we need to do is create an account. Head over to https://circleci.com/signup/ and create an account by using your GitHub or BitBucket account credentials. You will need to allow Circle CI to access some data in your SCM provider account of choice. This will allow Circle CI to be able to install webhooks and access data like your repository names, etc. This allows for automating processes such as build triggers when code is pushed to the repository.

Linking Your Repositories to Circle CI

You will need to link your repositories to Circle CI so builds can be triggered automatically when triggers you defined are triggered. Head over to the Circle CI Projects Dashboard and choose the user or organization you want to link to Circle CI. This will redirect you to a list of repositories that Circle CI is able to access under that account. For each repository, you will see a button/link that says “Set Up Project” as seen in the image below. Click on that button to start setting up your project

screenshot of CircleCI dashboard project list

This will bring up a webpage that has a code editor and some menu options. You may or may not need to change these based on the specific project you chose to set up. Make sure you have chosen the proper language in the upper left above the code editor. This will sometimes change the config shown in the code editor quite a bit, so make sure you have that correctly selected before moving forward. See Below

Dashboard of how to use Circle CI screenshot

Wrapping Up Initial Configuration

If the correct language has been selected and the selected config is showing in the editor, you can add the current config to your project to see the pipeline run. This default config will not do much except try to run unit tests. The default config will fail when it is run if you have a non-default way to run tests. You can at least see your pipeline triggered after a commit is pushed to make sure it’s hooked up correctly.

Setting Up A Basic Pipeline Config

Now let’s set up a basic pipeline config that we can actually have a pass when our Circle CI pipeline is triggered. The below example will print out a few stages in the pipeline and the last stage should be titled Print ‘Hello World’ in which it prints the words “Hello World”.

version: 2.1
orbs:
  node: circleci/[email protected]:
  build:
    docker:
      - image: circleci/node:12.20.1
    working_directory: /tmp/repo
    steps:
      - checkout
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies-
      - run:
          name: "Install NPM Packages"
          command: "npm install"
      - run:
          name: "Print 'Hello World'"
          command: "echo 'Hello World'"
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

There are many more advanced things you can add to your Circle CI pipeline. This is just the most simple example. In the next section, we will add a bit of customization to our config.

Customizing the Config File

We are going to customize our pipeline to sync all files in our project to an AWS S3 Bucket upon each commit and push. In order to do that, we will need to use a second Circle CI orb: aws-cli. To do this, add the following line to your config file:

version: 2.1
orbs:
  node: circleci/[email protected]
  aws-cli: circleci/[email protected] <<<<------ ADD THIS LINE

For the following steps to work, you will need a set of AWS IAM credentials you can use to upload files to S3. If you do not any AWS credentials, do that now by following the steps here.

Setting Up The Context

Next, we need to add what is called a context to our account. This is a set of credentials you can reference so you don’t hardcode them into your config file; which is ALWAYS a bad idea. You never want to check in files to your SCM tool with secret/sensitive values in them. So let’s add that context real quick.

Go to Circle CI Dashboard and then click Organization Settings in the left menu. Once you are in the Organization Settings menu, make sure that Contexts is selected on the left-hand side. Here is where we will create the context that holds our AWS credentials. In the main Contexts window, click the Create Contextbutton. Now give your context a name that is easy to remember. Now click on the newly created context. This will bring you to a screen that has 2 sections: Security and Environment Variables. 

Setting Up The AWS Environment Variables

In the Environment Variables section, click the Add Environment Variable button. We will add 2 environment variables to our context. First, add the variable named AWS_ACCESS_KEY_ID and then give it the value AWS_ACCESS_KEY_ID from your AWS IAM credential pair. Next, add a variable named AWS_SECRET_ACCESS_KEY and provide the corresponding value from your AWS IAM credential pair. Lastly, create an environment variable called AWS_DEFAULT_REGION and give it the value for one of the AWS regions you want to use. All of the AWS region names can be found here. Awesome! You’re done setting up your context!

Next, add a step in the build job to sync all of our files to an AWS S3 bucket. Add the following to your config file:

version: 2.1
orbs:
  node: circleci/[email protected]
  aws-cli: circleci/[email protected]
jobs:
  build:
    executor: aws-cli/default
    docker:
      - image: circleci/node:12.20.1
    working_directory: /tmp/repo
    steps:
      - checkout
      - aws-cli/setup
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies-
      - run:
          name: "Install NPM Packages"
          command: "npm install"
      - run:
          name: "Print 'Hello World'"
          command: "echo 'Hello World'"
      - run:
          name: "Sync Files to AWS S3"
          command: aws s3 sync . s3://[bucket name goes here] --exclude "*node_modules/*"
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

Now, the only thing left to do is to add a reference to the context so that the pipeline can access the AWS credentials it needs. Let’s do that now. Add the following to your config file:

version: 2.1
orbs:
  node: circleci/[email protected]
  aws-cli: circleci/[email protected]
jobs:
  build:
    docker:
      - image: circleci/node:12.20.1
    working_directory: /tmp/repo
    steps:
      - checkout
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies-
      - run:
          name: "Install NPM Packages"
          command: "npm install"
      - run:
          name: "Print 'Hello World'"
          command: "echo 'Hello World'"
      - run:
          name: "Sync Files to AWS S3"
          command: aws s3 sync . s3://[bucket name goes here] --exclude "*node_modules/*"- save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}
workflows:
  version: 2
  custom-workflow:
    jobs:
      - build:
          context: [your context name here]

Conclusion

That’s it! Your Circle CI pipeline should now auto-sync files to an AWS S3 bucket on each commit and push them to the remote repository! Now that you know how to use Circle CI, go improve your DevOps workflow!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail
CircleCI Jenkins CI Logos Image
GeneralTechnology Comparisons

Which Is Better? Circle CI vs Jenkins

by corey.walker
written by corey.walker 5 minutes read

Software development and automation of the process have advanced a great deal in recent years. There are now many different platforms you can utilize to automate your software development workflow. Utilizing one of these CI (Continuous Integration) and CD (Continuous Delivery) tools is a best practice for the software development lifecycle. It helps automate things when new code is added to an SCM platform such as GitHub or BitBucket.

Two of the most popular CI/CI platforms today are Circle CI and Jenkins. In this post, I will compare the two platforms and lay out the differences between each, and provide a list of what I believe are the pros and cons of each. Let’s get started!

Check out the related YouTube video:

YouTube video for Circle CI vs Jenkins

Circle CI

Circle CI is one of the most popular cloud-hosted CI/CD providers. It was founded in 2011 and is based in San Francisco, CA. Circle CI is among the most popular CI/CD platforms for open source projects. It has support for a variety of languages with multiple pricing plans available to suit most peoples’ needs. Circle CI is currently only available for GitHub and BitBucket.

Configuration

Circle CI can be configured just by creating a file in the root of your SCM repo called .circleci/config.yml. Details can be found here on how to configure this file and all the available options. This allows for the ability to copy the configuration file to multiple repositories and just edit the relevant details specific to that repo and everything will work.

Some CI/CD tools require setting up the process manually to start with. Then each time you create another project, you have to go through those same steps to set it up each time. That is not really ideal as some steps could be overlooked or missed between projects. This can cause some of your automated processes to not work correctly, and thus possibly cause issues down the road if they go unnoticed.

You can find steps to set up Circle CI with GitHub here. You can find steps to set up Circle CI with BitBucket here.

Pricing

Circle CI is always free for open-source projects. For projects with private repositories, Circle CI has a free plan that has limited “credits” per week. You can use this free plan forever if your projects are not constantly running builds. If your projects only need a few builds a week, this is a great option!

Beyond the free starter plan, Circle CI pricing is based on what they call “credits”. They do not have a paid plan that offers unlimited builds. This is something to keep in mind if you have many projects that are running builds on a consistent basis as this could spike the costs for your team if you do not estimate correctly. The paid plan starts at $30/month. You can find all pricing details for Circle CI here.

Supported Languages

You can find a list of programming languages Circle CI supports here.

Jenkins

Jenkins is one of the oldest CI/CD platforms available which started back in 2005. It has been installed millions of times. This makes it one of the most, if not THE most, popular CI/CD platforms in use today. Jenkins has over 1500 plugins to choose from to customize your CI/CD needs. It is open-source and thus does not cost anything for the software itself. The only cost involved is the infrastructure you run it on.

Whereas Circle CI has both cloud-based and on-premise enterprise solutions, Jenkins is only available to be run on-premise. They do not have a Jenkins-hosted cloud-based CI/CD service that you can subscribe to. There are some third-party cloud-based offerings such as Google Cloud’s Jenkins Cloud offering and Cloudbees Jenkins Platform.

Jenkins allows simultaneous builds to be run concurrently by default if you have the infrastructure to support it. Numerous large companies use Jenkins for their CI/CD needs.

Although Jenkins does not have a native cloud-based offering directly, there are a few hosting providers that offer such an offering. One of the major draws of Jenkins, however, is the customizability using the multitude of plugins available.

Pros and Cons

Circle CI Pros

These are the benefits of Circle CI over Jenkins:

  • Cloud-based offering
  • No need to pay for, configure or maintain your own infrastructure
  • Large user base and well-vetted
  • Forever free starter plan for projects with private repositories

Circle CI Cons

  • Not as many plugins available to simplify the customization of CI/CD flow
  • Only available for repositories stored in GitHub or BitBucket
  • Not unlimited builds. Must keep purchasing credits which are used at varying rates based on OS and build image size

Jenkins Pros

  • Open-source software, and thus well vetted
  • Over 1,500 plugins to help simplify and customize CI/CD flow
  • Completely free software, only need to pay for the infrastructure you want to allocate
  • More widely used than Circle CI
  • More community-based support
  • More SCM integrations than just GitHub and BitBucket

Jenkins Cons

  • No cloud-based subscription offering directly from the vendor themselves. Requires third-party platforms hosting Jenkins in the cloud
  • Have to pay for, configure, and maintain your own infrastructure to run Jenkins
  • Bit of a learning curve to know which plugins to use for different scenarios

Conclusion

The best platform for you all depends on your specific needs. If you do not have a large monthly budget or extra man-hours to spend on infrastructure issues, then a cloud-based provider such as Circle CI will be a better choice. Just note that Circle CI only integrates with GitHub and Bitbucket as I write this (June 2020).

You would probably be better off using Jenkins for now if using SCM other than GitHub or BitBucket. Try one of the third-party cloud-based Jenkins offerings referenced earlier if on a budget.

You can also check out my posts comparing Travis CI vs Jenkins and Travis CI vs Circle CI.

Please let me know which platform you think is better or that you prefer using and why in the comments!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail
TravisCI vs CircleCI Logos Image
GeneralTechnology Comparisons

Which Is Better? Travis CI vs Circle CI

by corey.walker
written by corey.walker 6 minutes read

Software development and automation of the process have advanced a great deal in recent years. There are now many different platforms you can utilize to automate your software development workflow. Utilizing one of these CI (Continuous Integration) and CD (Continuous Delivery) tools is a best practice for the software development lifecycle. It helps to automate things when new changes are added. Do you know which is better for your needs? Do you know the differences between Travis CI vs Circle CI?

In this post, I will compare the two platforms and lay out the differences between each, and provide a list of what I believe are the pros and cons of each. Let’s get started!

Check out our related YouTube video:

YouTube video for Travis CI vs Circle CI

Travis CI

Founded in 2011, Travis CI is the oldest and most mature cloud-hosted CI/CD provider. They are based in Berlin, Germany. They are among the most popular CI/CD platforms for open source projects. It has support for a variety of languages with multiple pricing plans available to suit most peoples’ needs. It is currently only available for GitHub and BitBucket.

Configuration

Configuration is as easy as just creating a file in the root of your SCM repo called .travis.yml. You can find details on how to configure this file and all the available options here. This allows for the ability to copy the configuration file to multiple repositories and just edit the relevant details specific to that repo and everything will work.

Some CI/CD tools require setting up the process manually to start with, and each time you create another project, you have to go through those same steps to set it up each time. That is not really ideal as some steps could be overlooked or missed from time to time. This can cause some of your automated processes to not work correctly, and thus possibly cause issues down the road if it goes unnoticed.

You can find steps to set up Travis CI with GitHub here and steps to set up with BitBucket here.

Pricing

Always free for open-source projects. For projects with private repositories, your first 100 builds are free in order to allow you to try it out even for private repositories. For unlimited builds for projects with private repos, there are a variety of plans for developers and teams of all sizes starting at $65/month as of this writing (June 2020). You can find the full list of plan options for private repositories here.

Supported Languages

They support a wide variety of programming languages. They support 32 different languages that can be found here and here. You can find the docs on how to submit support for a new language here.

They does not charge extra for access to macOS build environments. Circle CI does not charge “extra” per se, but requires more “credits” per minute than Linux build environments and thus can eat through your credits much faster than expected.

Circle CI

Also started in 2011, Circle CI has been around as long as Travis CI. They do not have quite as large of a customer base as Travis CI but are an equally powerful CI/CD platform that is based in San Francisco, CA. It also has support for a variety of languages with multiple pricing plans available to suit most peoples’ needs just as Travis CI does. Circle CI also is currently only available for GitHub and BitBucket.

Configuration

Configuration for Circle CI is just as easy by creating a directory in the root of your SCM repo called .circleci. Inside this directory, you create a file config.yml. You can find details on how to configure this file and all the available options here. This allows for the ability to copy the configuration file to multiple repositories and just edit the relevant details specific to that repo and everything will work just like Travis CI.

You can find steps to set up Circle CI with GitHub here. Steps to set up Circle CI with BitBucket are found here.

Pricing

Circle CI is always free for open-source projects. For projects with private repositories, you have multiple plans available with a Free plan available with limited credits each week. So if you have a project that doesn’t require a lot of changes and thus not many builds each week, this could be a permanent free solution.

Unlike Travis CI where you buy different plans which are all unlimited builds and build minutes but only differ by the number of concurrent builds, Circle CI plans are based on “credits”. This can allow you to auto-scale to the capacity of concurrent builds as needed by using more credits for each additional concurrent build. Pricing starts at $30/month which includes 3 users and 25,000 credits with each additional 25,000 credits costing $15 and an additional $15 per additional user.

Circle Ci charges more credits per minute for macOS builds than for the Linux Docker builds. The differences between normal Linux VM and macOS are minimal.

Supported Languages

Circle CI also supports a wide variety of programming languages. You can find information on Circle CI’s supported languages here.

Pros and Cons

Travis CI Pros

  • Unlimited builds for each paid plan
  • More languages supported by default
  • Build Matrices

Travis CI Cons

  • Higher starting price point for paid plans
  • No completely free account for projects with private repos
  • No concurrent builds until you pay more per month for higher-priced plans

Circle CI Pros

  • Completely free account for projects with private repos with limited build minutes each week
  • Cheaper starting price point for paid plans
  • Can automatically have multiple concurrent builds at the lowest price point

Circle CI Cons

  • Paid plans are based on “credits”. Credits are spent for each minute of build time
  • Credits are used at different rates depending on OS and VM size. Thus if you are building on Windows or macOS, you spend more credits per minute than Docker or Linux VM builds.

Conclusion

The best platform for you all depends on your specific needs. If you are only building projects that only have open source repositories, then either platform will be free. Thus, it’s all based on personal preference.

If you are building projects that contain private repositories and are heavily utilizing Windows or macOS VMs, it would most likely be cheaper, in the long run, to go with Travis CI. Circle CI will be cheaper if you have projects that are not updated very frequently and can be built on Linux, or if you can mostly utilize Circle Ci’s Docker Linux builds.

The other major thing to consider is the language being used for your projects. If one platform offers it and the other platform doesn’t, then the platform that does offer it would probably suit your needs better.

You can also check out my comparison between Travis CI and Jenkins or Circle CI and Jenkins.

Please let me know which platform you think is better and why in the comments!

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail
Require Successful Circle CI builds for GitHub PRs
Tutorials

How To Require Circle CI Builds For Pull Requests

by corey.walker
written by corey.walker 4 minutes read


You are a software developer and/or a project manager. You and your team want to make sure that new code changes don’t break your project before pushing to production. Great! Well, how do we go about making sure that we do everything we can to make sure that doesn’t happen? I’ll walk you through how to require successful Circle CI builds before pull requests can be merged!

One great thing to add to you workflow is requiring successful builds with the new code before merging. If you are using GitHub and Circle CI, 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.

Setup GitHub And Circle CI

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 Circle CI and sign in with GitHub. Once you are logged in to Circle CI, you should see a screen similar to the following:

Circle CI dashboard showing projects
Circle CI dashboard showing projects

Setting Up Configuration File

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 Circle CI integrates with and has default images for. It will look like the following:

OS and language options in Circle CI
OS and language options in Circle CI

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 Circle CI configuration file that resembles the following:

# Javascript Node Circle CI 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 Circle CI 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 Circle CI, 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:

GitHub repository branch protection rules
GitHub repository branch protection rules

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 PRs from being merged if 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.

Conclusion

After applying these changes to GitHub, any future pull requests for the repository and for the specified branch(es). This should help keep errors from reaching your production environments.

0 comments
0 FacebookTwitterLinkedinTumblrRedditWhatsappTelegramCopy LinkPocketEmail