Comparing GitHub Actions vs Jenkins: CI showdown

What's better: GitHub Actions or Jenkins? It depends! In this post, we compare and contrast Jenkins and GitHub Actions and chat use cases so you can get a sense of which CI tool is best for your needs.

CI/CD has gone from being a buzzword thrown around the tech giants to being a staple of many software development shops. But, much like deciding to move to the cloud (or deciding to let yoru toddler dress you) deciding to adopt CI/CD means you need to make a lot of follow-up decisions.

Get started with ACG and transform your career with courses and real hands-on labs in AWS, Microsoft Azure, Google Cloud, and beyond.

For migrating to the cloud, you will need to pick — at least — one cloud provider. (For the toddler picking your outfit, you will need to ask yourself some hard questions about how you got where you are.) When you decide to adopt CI/CD, you will need to pick a tool, and there are a lot of them, seemingly with more added every year. 

So, let's compare and contrast two powerhouses in the CI tool space: Cloudbees’ Jenkins, one of the trailblazers in the space, and GitHub Actions, brought to you by the people who brought the addictive thrill of social media to version control.

We’ll compare four dimensions: developer experience, security, operational complexity, and cost. We won’t pick a winner (sorry), because in the end, the best fit depends on specific circumstances. But we will highlight strengths and tie them to specific use cases so you can get a sense of what makes the most sense for you. 

First up, we have developer experience. "What is developer experience?’" you may ask.

In a nutshell, developer experience is UX, but for developers. How does your team feel about using the tool? Is it easy to learn? Are error messages clear? Is there community support?

Jenkins has been around for over 10 years now. It boasts an astounding number of community plugins for a wide range of tools and frameworks. Pretty much anything you can think of needing to do, there’s a plugin for it. 

The downside to all these plugins is that sometimes trying to find something that works for you can feel like cutting through a jungle with a machete. Also, Jenkinsfiles are written groovy, which, if you’re comfortable with it — groovy. But I’ve seens a number of newer developers struggle with it — especially if they don’t often work with Java. 

GitHub Actions, on the other hand, doesn't have the years of iteration and robust community support archives. However, user-created Community Actions can support a wide range of use cases.

The downside to the Community Actions approach is that it limits the use of open-source solutions to steps run in jobs, without direct support for other potential value-add offerings around security, cost, or analytics. GitHub Actions workflows are written in YAML, which seems more common in DevOps tooling these days, and is easier to pick up for newcomers. 

So if Jenkins can sometimes be a lush jungle, GitHub Actions can feel like a walled garden. 

There is a lot of overlap in the security considerations for Jenkins and GitHub Actions. Each open source solution you bring into your environment needs to be independently vetted.

GitHub Actions has some additional considerations to be mindful of. GitHub comes in two distinct flavors: GitHub Enterprise and GitHub.com.

• GitHub Enterprise is a server you run in your own environment, and is similar to how you would run a Jenkins server.

• GitHub.com is the more well known SaaS offering. With GitHub.com, you don’t need to worry about updating and patching a server, but any GitHub user can create a pull request for a public repository. This can allow malicious users to run their code against your repository. This can cost money, impact environments, and compromise secrets. This is the tradeoff of public repositories — when asking for feedback from the community, you get the good, and need to mitigate the bad. 

WATCH: Post-COVID DevOps: Accelerating the Future
How has COVID affected — or even accelerated — DevOps best practices for engineering teams? Watch this free, on-demand panel discussion with DevOps leaders as we explore DevOps in a post-COVID world.

Operational complexity is how much bandwidth the tool will use from an ops/infrastructure team.

For this catagory, Jenkins and GitHub Enterprise are in the same boat: both require management of the servers hosting the tool (patching, updates, backups, etc), as well managing the runners or nodes that will actually execute the jobs. 

GitHub.com, on the other hand, can have very low operational cost. Since both the platform and the runners are managed by GitHub, there are no servers to manage. You can use your own custom runners with GitHub.com if you want, and there are some compelling use cases for that, but its not needed. 

Both Jenkins and GitHub Actions can start off very low cost, but if you don’t have a strategy in place, costs can ramp up quickly.

Of course, costs are not just the bill you get every month from the vendor. If a tool requires 20 resource hours a sprint to maintain, that's a cost. If new hires need to spend a week learning how to use the tool before they can start coding, that's a cost. If an out-of-date open-source plugin results in a data breach, that’s a cost.

So when minimizing costs, often times its best to take a broader view than what’s covered in this section. 

Jenkins is fully open source, so you can install it on a server and get going. You can add worker nodes, open-source plugins, and 3rd party integrations and get a robust CI/CD solution going without paying for more than the cost of the servers you’re running everything on. However, Cloudbees does offer enterprise options with some potenially valuable enhancements. 

Github.com, on the other hand does not offer an open-source option, and it charges based on how many minutes a job runs. GitHub free account holders get a budget of free minutes a month, which is good for learning, or supporting a personal project or two, but once that budget is exhausted, costs can mount quickly. You can reduce costs with a custom runner, where again, you only pay for the cost of the underlying server, but that increases your operational complexity. 

In the battle of the CI tools, there are no losers. (So hopefully that means we’re all winners?)

Both GitHub Actions and Jenkins can add a lot of CI goodness to your projects, but they do it in meaningfully different ways. Chosing the tool that’s best for you will make the process of adding CI much easier and you’ll start seeing the added value much faster. 

To learn more about GitHub Actions, check out the new GitHub Actions Deep Dive course. Or, if you think Jenkins may be the tool for you, you can learn more about Jenkins with ACG’s Learn Jenkins by Doing collection of hands-on labs or our Jenkins Fundamentals courses.

Either way, have fun, and automate all the things!

Get the Cloud Dictionary of Pain
Speaking cloud doesn’t have to be hard. We analyzed millions of responses to ID the top concepts that trip people up. Grab this cloud guide for succinct definitions of some of the most painful cloud terms.