Using GitHub Actions vs Jenkins

Recently I had to go through the process setting up a new CI/CD pipeline at work, and because the current workflow in our monorepo heavily depends on GitHub actions, I decided to gather some of the benefits of using GitHub Actions (GHA) over Jenkins.

Let me know on X if you would like to see more in depth practical examples of using GitHub Actions in a large monorepo.

Without further ado, enjoy my brief document on GitHub Actions, hopefully this helps you out.

Seamless Integration & Ease of Use

GHA seamlessly integrates with the GitHub ecosystem, offering unparalleled ease of use. Conversely, Jenkins, an open-source powerhouse, demands separate infrastructure setup and maintenance. The installation, configuration, and management of Jenkins are complex tasks, requiring significant time and effort. Additionally, Jenkins’ knowledge tends to be siloed due to its complexity, in contrast to GHA’s user-friendly maintenance and setup. GHA is built directly into GitHub, negating the need for separate infrastructure.

Self hosted runners

Both GitHub Actions and Jenkins provide options for self-hosted runners, but one distinct advantage of GHA self-hosted runners is that we can easily pick and choose when to use a self-hosted runner with a single line. This allows easy access to internally hosted services and sensitive data when a workflow run needs it.

Developer Productivity and Workflow Flexibility

GHA provides flexibility by allowing actions to trigger on a variety of events, such as push or pull request updates. This allows teams to customize their workflows according to their unique needs. For example, a ‘push’ event may trigger a full CI/CD pipeline, whereas a ‘pull request’ update could trigger unit tests. Jenkins also supports event-driven triggers but lacks the direct integration with GitHub repositories to provide the same level of granular control and responsiveness.

Contextual Understanding

Another advantage of GHA is that it operates within the GitHub context. This provides extensive metadata about the triggering event and the GitHub environment. Developers can get information about the PR it was triggered from, labels, full commit history and more. This empowers developers to create detailed, conditional workflows. Jenkins, despite being robust and extensible, lacks this innate contextual understanding and cannot provide the same level of fine-tuned control out of the box.

Security

GHA offers a robust security model, with secrets stored encrypted and available to workflows running in the same repository.

Scripting language flexibility

GHA supports a variety of scripting languages out of the box, this gives developers the freedom to write their automation scripts in the language they are most comfortable with.

Efficient Caching

GHA provides advanced caching capabilities, which can significantly speed up builds. This is particularly beneficial for mono-repos where you might need to build multiple packages per PR.

Fetch Depth Control

One major advantage of using GHA is that developers can control the fetch depth of the git checkout operation on a per-job basis. This means that if you don’t require the entire git history, a shallow clone can be used to speed up the process. This level of control is harder to achieve in Jenkins

Configuration as Code

With GHA, all the configuration details are stored within the repository rather than in a GUI, this promotes better version control, audit trails and collaboration.

Collaboration

Jenkins’ complexity often limits the knowledge circle to a few engineers, making it challenging for other developers to step in and make modifications. In contrast, GHA’s simplicity promotes wider developer participation in setting up and maintaining a pipeline.