Complete GitHub Actions Intro and Guide

If you are wondering what GitHub Actions is and how it might help you with software delivery, we’ve created this intro and guide to help you out. 

What is GitHub Actions?

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform. It enables users to automate various GitHub events, such as cloning a repository, generating Docker images, and testing scripts. It will kick off workflows with GitHub events like push, issue creation, or a new release. For example, you can create a workflow to run automatically to add the appropriate labels whenever someone creates a new issue in your repository, or you can develop one to set environment variables whenever someone kicks off one or more jobs. 

Before we dive deeper into GitHub Actions, if you need more introductory info on CI/CD and how this topic fits into software development practices, check out our blog explaining what is CI/CD  You may also be interested to read more about what is continuous integration and the benefits of CI. 

GitHub Actions Features

GitHub Actions makes it easy to automate all your software workflows, so you can build, test, and deploy your code right from GitHub. GitHub Action features include:

Workflows Based on YAML files 

To automate development workflows with GitHub Actions, users create definitions using a workflow file, or YAML file, and store these files in the GitHub repository under the .github/workflows directory. A workflow run is triggered three ways: via an external event, a scheduled event, or a GitHub repository event (such as push or pull requests to a GitHub repo or issue creation). 

Secrets Management

GitHub Actions provides different ways of scoping secrets:

• Secrets can be set up at a global organization-wide level
• Instead of having to update secrets across a number of Git repositories, they can be handled in a centralized place
• It’s also  possible to restrict whether secrets are exposed to forked repositories or not 

Hosted Runners for Linux, MacOS, Windows, ARM, and Containers

If you would like to use GitHub hosted runners, GitHub Actions includes hosted runners for multiple operating systems, so users can build and test a wide variety of projects. GitHub Actions runs on a VM or inside a container. Hosting your own runners is possible in a virtual environment on VMs in the cloud or on-prem. 

Available as SaaS & On-Premises

GitHub Actions used to be SaaS-only, but the company added an on-premise version for customers on GitHub Enterprise Server 3.0 or later. The newest version runs on premises on your operating system of choice or in a data center environment. From our understanding, there are some minor limitations, but most actions are available on the on-prem version for multiple operating systems. 

Broad Language Support

GitHub Actions supports Node.js, Python, Java, Ruby, PHP, Go, Rust, .NET, and more. Users can build, test, and deploy applications in their language of choice on any operating system.

Matrix Builds 

Save time with matrix workflows that simultaneously test across multiple operating systems and versions of your runtime.

Multi-container Testing

Test your web service and its database in your workflow run by adding some docker-compose to the workflow file, or YAML file (the YAML file extension is .yml). 

Live Logs

Users can see their workflow run in real time in GitHub Actions. It’s one click to copy a link that highlights a specific line number to share a CI/CD failure.

Dockerfile Support 

There is Dockerfile support for GitHub Actions. GitHub Actions can publish artifacts to GitHub Packages or another package hosting provider such as Docker Hub. Users can also leverage actions built by other developers. For example, there is an action available called Check Ansible Ubuntu latest that enables you to test your Ansible role or your playbook in a Docker Container. 

GitHub Actions Pricing

Many users wonder, is GitHub Actions free? GitHub Actions is freely available for public repositories but private ones have a 2,000 minutes limit on their runner's build time. More minutes are available in paid plans. If a customer goes beyond a plan’s allotted minutes, they’re billed per minute based on the runner platform. Self-hosted runners are free and the CI/CD capabilities are also available in the GitHub Enterprise self-hosted version. 

According to the GitHub website, GitHub Actions CI pricing is as follows: 

“GitHub Actions usage is free for standard GitHub-hosted runners in public repositories, and for self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage for use with GitHub-hosted runners, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits.

If you are a monthly-billed customer, your account will have a default spending limit of 0 US dollars (USD), which prevents additional usage of minutes or storage for private repositories beyond the amounts included with your account. If you pay your account by invoice, your account will have an unlimited default spending limit. 

Minutes reset every month, while storage usage does not.”

GitHub Actions Review: Pros and Cons

GitHub Actions offers pros and cons that potential users should be aware of before migrating to GitHub Actions. 

Ease of Use 

Users can get up and running with GitHub Actions fairly quickly regardless of operating system. Assuming the user has a GitHub repo already, it’s possible to add the first workflow into the repo and run an action. Then, you can quickly do your first workflow run. If you select the option to “set up a workflow yourself,” GitHub creates a main.yml file with the .github/workflows directory for you with a templated workflow run that you can edit. 

Managing secrets is painless: users can set secrets at the organization level as well as at the repo level, which is relatively flexible. 

One of the larger sticking points is that the way data is passed around workflows between jobs. This can be a bit tricky at first and there’s definitely a learning curve. When trying to pass data between actions and jobs, you’ll find yourself needing to use cryptic action syntax or direct .env file insertion to chain each job’s state together. 

Like most CI/CD providers, Github Actions has third-party actions that you can use as semi plug-and-play functionality. IT can be hit or miss whether or not a task has already been solved by a publicly-available GitHub Action – otherwise, you’ll need to write your own. Given that, you’ll find yourself needing to code a lot when working with GitHub Actions. 

Lastly, because GitHub Actions is a relatively newer offering, it still doesn’t have any sort of good reporting and oversight on what’s happening outside of a given repo. There’s no high-level overview of watching executions with a timeline or native deployment tracking, which is something Harness gives you. 

Limited Self-Service

GitHub Actions will recommend CI workflows based on the programming language and framework in your repository, which is nice but far from a true self-serve experience, especially if you use a software configuration management (SCM) tool different from GitHub. Being SCM agnostic has advantages since GitHub Actions is finely tuned to listen to events that happen in GitHub SCM and maybe not so much to your SCM tool of choice. Testing with GitHub Actions doesn't go beyond providing a test result on the pull request created.

Lacks Continuous Verification Functionality

Continuous verification is the process of monitoring your app for abnormalities after a deployment. 

For example, continuous verification can catch a latency issue or 5xx errors and automatically roll back an app to the previous version. The concept of continuous verification is to catch errors as quickly as possible – ideally, before customers notice – and make a seamless transition back to the previous version of the application. 

There are some basic deployment status actions for GitHub Actions out there in the GitHub marketplace, but those only tell you if a deployment passed/failed, not how it’s doing post-deployment. 

It seems that to have complete visibility into deployments, you would need to write your own actions within GitHub Actions to achieve this. There are integrations into some observability tools like Lightstep, so it could be done – but it would have to be done manually using a GitHub API. 

Requires Manual Scripting 

GitHub Actions does unfortunately require a decent amount of scripting. The good part is that if you do have to write an action, you can publish it as a container image, so you can write it in whatever language you want. 

There are also pre-written actions out there on the GitHub marketplace, including integrations to plenty of tools. An example of a pre-written action is one for managing workflow runs, that will check to see if the same workflow is already running from a previous commit, and if so, to wait for it to finish

However, the bad part is that while scripting isn’t the worst way to spend our time, it is time that could be spent shipping code. It is toil. It’s something that needs maintenance by your brightest engineers, which ultimately takes away from valuable coding time. 

Canary Deployments Can Be Challenging

An Azure user put together a helpful tutorial on how to do canary deployments with GitHub Actions and Azure using Linkerd. It is possible, but as the user noted, “An end-to-end solution, fully automated and based on metrics, in a more complex production application is quite challenging. […] While I think the GitHub Action works well, I am not in favor of driving all this from GitHub, Azure DevOps, and similar solutions. There’s just not enough control.” 

The adage “Just because you can doesn’t mean you should” remains true here. 

Limitations with Secrets Management 

GitHub Actions doesn’t have granular access control mechanisms for secrets management. Also, secrets in GitHub Actions are natively handled for CI/CD – third parties, like HashiCorp Vault, cannot be leveraged. 

Lacks Native Metrics Dashboards  

There are four key metrics when it comes to software development: 

1. Lead Time, or the average amount of time it takes from the time code is checked in to the version control system to the point in time where it is deployed to production
2. Deployment Frequency, which is the number of times deploys to production occur in a time period 
3. Mean Time to Restore (MTTR) or how long it takes to resolve or rollback an issue in production
4. Change Failure Rate, which is what percentage of changes to production fail

These metrics are one of the core concepts for truly understanding performance. However, GitHub Actions does not provide native metrics dashboards. 

That wraps up our GitHub Actions review. If you are looking for more information on the best continuous integration tools out there, we have a handy guide.  
Looking for True CI/CD?

If you’re considering adding a CI/CD solution to your software development practices, Harness integrates with and orchestrates your entire software stack. And, it uses AI/ML to automate and accelerate your software delivery. 

‍Try Harness for free today.