#Should You Use Github Actions for Continuous Integration (CI)? – CloudSavvy IT

Continuous Integration is crucial for any active repository that needs routine building and testing. Github supports CI pipelines in the form of Github Actions—builds that run in the cloud, automatically, with just a bit of setup.

What Is Continuous Integration?

While some codebases, like certain web apps, can be deployed directly from their source files, others require additional processing, compilation, and, most importantly, unit testing. These builds can be complicated and even resource intensive in the case of languages like C++.

Continuous Integration is the process of automating testing and building for new commits to your source code. Commonly, this is used with software like Jenkins running on a “build server” that will handle the actual compilation.

Automated code compilation is such a useful service for software teams that it’s now offered by cloud providers, including Github, where it integrates nicely with the rest of their services.

What Are Github Actions?

Github Actions are cloud-based tasks that can be used to automate your repository. They’re commonly used to run automated builds for new commits or releases, which can be useful for continuous software testing. However, they can also be used for non-CI related automation, such as working with issues and pull requests, running cron jobs, or triggering commands based on actions in your account.

As far as CI goes, Github Actions are quite useful. Most CI pipelines require you to set up complicated software like Jenkins or be using a specific cloud service like AWS CodePipeline. Github Actions are very simple, and just require you to commit a configuration file to .github/workflows/ to enable an action.

On top of that, Github is usually able to pick up on what kind of project you’re making and offer suggestions for action configs from its library of examples. For example, this Java project was up and running with automated builds in only a few minutes with some minor tweaks to

You can have multiple actions in the same repo; for example, maybe you want to set up automated builds for every commit on the dev branch, but you only want builds for each new tagged release on the master branch. You can make two separate YAML files with different criteria.

While Actions are very useful for doing builds and testing, they can also run commands and connect with other services, allowing them to automate the delivery and deployment processes as well. For example, you could have an action on the release branch take each new tagged release and upload it to your servers for deployment.

By default, Github Actions builds will publish build artifacts (whatever was outputted by the build process) to a zip file for each run. This works well if you’re just running tests, but if you want to do automated delivery, you can also set them up to automatically publish new releases, or push to a package/container registry like NPM or the Docker hub.

The exact configuration for your repository will vary depending on what your build process is, but Github does a good job of providing solid examples to start with, and the general setup is largely the same. If you’d like to learn more about getting started with GH Actions, you can read our guide on setting them up.

Github Actions Pricing

Fortunately, Github has the money to sponsor open-source software, so Actions are entirely free for public repositories. You can use them as much as you want, or store as many build artifacts as you want—there’s no hard limit unless you’re being abusive, just like the rest of Github.

For private repositories, every account automatically has 2000 minutes of build time every month, which is very generous. That’s almost a day and a half of continuous building, so you’d have to be doing some seriously long builds—or tons of commits—to hit that number. You’re more likely to hit the 500 MB storage limit for free accounts. However, if you are building on every commit, with long build times, and committing often, you can run that number out.

Github Pro users ($4/month) get 3000 minutes and 1 GB of storage, as do organizations using the Github Team plan, which is $4 per user, per month.

Github Enterprise, which costs $21 per user, per month, gives 50,000 minutes of build minutes, which is 35 straight days of builds, letting you run builds 24/7 and then some.

If you do go over on any plan, you’ll simply be billed for the extra minutes used. The rates are pretty fair, with an extra 2000 minutes costing $16.

Should You Use Actions or Your Own Build Server?

CI/CD starts with version control tracking. Automated builds are usually run for each commit or major release, and most standalone build server systems, like Jenkins or TeamCity, will integrate with your git repository to provide this functionality.

This makes Github’s own CI solution pretty useful in comparison—it’s integrated directly into the service you’re already using and is extremely simple to get up and running. All you have to do is commit the build configuration file to your .github folder, and Github will pick it up and run it. While standalone services can be useful for enterprise deployments, for the average user, the simplicity of using Github Actions is easier than even installing a custom build server.

Github Actions are also able to be used for more than just automated builds. They support all kinds of repository automation, including working with issues and pull requests.

With that said, Github Actions aren’t as full featured as running your own server for it, and if you do a lot of regular or complicated builds, you should look into setting up a Jenkins server. If you do a lot of CPU-intensive builds, Jenkins can also be good for that, but Github Actions also supports using your own server to run builds on.

RELATED: How to Install and Use Jenkins to Build a CI/CD Pipeline