GitHub Actions is a platform built into GitHub that automates software building, testing, and deployment. GitHub, owned by Microsoft, is a hosting service for software development using Git, an open source version control and collaboration program developed by Linus Torvalds. Git and GitHub are already used by many programmers and software shops as the basis for their development practices, including the automated continuous integration and continuous delivery pipelines that carry projects through the build, test, and deploy cycle. GitHub Actions provides GitHub users with what GitHub calls an “API for cause and effect.” You can use the platform to automate all sorts of behaviors based on various triggers.

GitHub introduced GitHub Actions in 2018. Because of GitHub’s open nature, it’s not the only tool that you can use to implement CI/CD automation for GitHub-based projects; others, such as Azure Pipelines and Jenkins, may be preferable in some situations. But because GitHub Actions is integrated with the GitHub platform as a whole, users don’t need to worry about the underlying infrastructure. Its overall workflow is also designed with GitHub in mind, which will make it an attractive option for many. 

How GitHub Actions works

One of the best ways to understand how GitHub Actions works is to consider the terminology that describes its individual components. We’ll start with the name, “GitHub Actions.” We’re following GitHub’s lead in treating that as a singular noun (“GitHub Actions is…”), which names the platform as a whole. There’s also a component of the platform called an “action” (small “a”), which we’ll discuss shortly.

Now, let’s look at some of the components of the platform:

• Event: An event is what gets a GitHub Actions automated pipeline rolling. This event could be something specific that happens within a repository—a pull request or commit being pushed, for instance—or a scheduled trigger, a post to a REST API, or even just a manual command.
• Workflow: Any of these events can trigger a workflow, which is the overarching term for an automated process that you’re using GitHub Actions to put together: you could use a workflow to deploy your application when a new release is ready, for instance, or to add appropriate labels when someone opens a new issue.

  A workflow is defined in a YAML file saved in the .github/workflows directory of your repository: check out the GitHub docs for the syntax. This file will define the events that can trigger the workflow, along with the actual things you want the workflow to do.

• Jobs: The things you want the workflow to do are grouped into one or more jobs. Each job is a set of steps that happen in an order that you define; your workflow may consist of multiple jobs that run in parallel, or that follow one another in a predefined sequence, or some combination of the two. You can also create dependencies between jobs. For instance, you might have multiple build jobs running in parallel for different chip architectures. Once all those jobs completed, another job would package up the builds.
• Actions: An individual step within a job may consist of a simple shell script, but if you need something more complex, you can also use an action (note the small a). An action consists of code that you write that interacts with your GitHub repository; you can use GitHub’s API for this, or any available third-party API. The tasks actions perform can range from deploying code when it’s ready for production to sending an SMS alert to on-call developers to deal with urgent issues. Actions can be written to run inside a Docker container, though this is not required.

  One of the key points of actions is that they are reusable. While shell script calls can be simply included in the YAML file that defines your workflow, actions are standalone applications that are referenced in the YAML file and can be used by multiple workflows across your organization. This sort of reusability is one of the most powerful aspects of actions, and is what made them important enough that they served as the namesake for GitHub Actions as a whole. You can also make use of the broad variety of third-party created actions in the GitHub Actions marketplace; despite the name, these actions are free to use and mostly open source, and you can also contribute your own actions to the marketplace.

• Runners: A runner is the server on which a job runs. Each job within a workflow gets its own runner; as you might expect, these are generally virtual machines, and are freshly provisioned for your job. GitHub provides hosted virtual machines for this purpose—running Ubuntu Linux, Microsoft Windows, or macOS—but if you need your job to run on a specific hardware configuration or operating system, you can host a runner yourself.

Examples of GitHub Actions

The GitHub docs include examples to help you understand how GitHub Actions works. To start, you could test your code on a runner. Another example demonstrates how to work with GitHub Actions from the GitHub command-line interface.

An example that goes further—and that may be of particular interest in exploring the power of GitHub Actions—involves what GitHub calls a matrix strategy. In this type of workflow, you would use variables when defining a job in order to create multiple job runs that differ based on the values of the variables. As GitHub’s in-depth example shows, this is a good way to automatically test your code against different language or operating system versions; you can change the values of the variables to choose new test environments.

Fireship.io has some more useful GitHub Actions examples for you to peruse, including demonstrations of how to publish a package to NPM when you create a new release; how to automatically send email, Slack, or Discord messages updating users on job progress; or how to schedule a background job at a specific time or at specific intervals.

Security best practices for GitHub Actions

If you’re running GitHub Actions on code in a GitHub repo, you’re almost certainly working with a distributed codebase, and that brings up security complications. GitHub recommends these best practices to ensure that your workflows are secure:

• Use secrets for sensitive data: You should never hardcode things like passwords or API login data into your workflow definitions. GitHub allows you to save such information as encrypted secrets; indeed, if you use a secret to generate another piece of information that should also be secured, you can register that value as a secret, too.
• Keep tabs on your workflow files: If an attacker manages to alter your workflow definitions, you could be opening your systems to infiltration or attack just by running a job. Use the GitHub code owners feature to regulate access to directories where you keep the YAML files for your workflows.
• Guard against script injections: Like any application that can accept input, actions can be tricked into malicious behavior if an attacker manages to pass in executable code. You should apply the same defensive coding techniques to GitHub Actions that you would apply to any other potentially sensitive code.
• Be careful with third-party code: In addition to the GitHub Actions marketplace, there are many other places where community members share actions and workflow code. These resources can be helpful, but you should never plug third-party code into your codebase without consideration. Be sure to subject these modules to the same level of security scrutiny as any other code you would put into production.

For more in-depth security information, check out GitHub’s guide to security hardening for GitHub Actions.

Integrating GitHub Actions with other platforms

Because GitHub is a relatively open platform and GitHub Actions workflows are described in declarative YAML, there are a few ways you can integrate your GitHub Actions code with other platforms:

• AWS: You can reuse your actions on CodeCatalyst, AWS’s managed software development service, by using a wrapper to turn them into conceptually similar CodeCatalyst actions.
• Azure: Microsoft (which is GitHub’s ultimate corporate parent, although it takes a fairly hands-off attitude) makes it possible to write a GitHub Actions workflow that deploys code to the Azure App Service hosting platform.
• Visual Studio: Speaking of Microsoft, the company’s venerable Visual Studio IDE has an extension that lets you create and manage GitHub Actions workflows without leaving the editor.
• Google Cloud: Google has made available a number of actions that help you integrate code stored in a GitHub repository with its Google Cloud service, including one that lets you take advantage of Cloud Deploy to roll out code into production.

Do I need to pay for GitHub Actions?

GitHub Actions is free if your jobs execute on standard GitHub-hosted runners in public repositories, or if you host your runners yourself. If you’re using a private repo, you get a certain amount of storage and compute time for free but must pay once you exceed those limits. There are also overall limits on the number of concurrent jobs you can run using GitHub-hosed runners, as well as on API requests per hour and workflow runtime. See the GitHub docs for more details.

Alternatives to GitHub Actions

There are other tools on the market that automate the CI/CD process and therefore occupy much of the same space as GitHub Actions. Perhaps one of the most prominent and mature is Jenkins, an open source offering that traces its roots back to 2004. Jenkins can work with GitHub repositories via plugins—as well as code in any number of other environments—and is generally quite flexible, although the learning curve may be steep compared to GitHub Actions.

In general, GitHub Actions’ greatest strength is its tight integration with GitHub. Other hosting services have their own equivalents; GitLab has GitLab CI, for instance, and there is also AWS CodeCataylst actions. If you’re using GitHub and you aren’t already invested in a cross-platform tool like Jenkins, GitHub Actions is a logical choice for your automated CI/CD needs.