Github Actions enables you to create custom software development lifecycle workflows directly in your Github repository. These workflows are made out of different tasks so-called actions that can be run automatically on certain events.

This enables you to include Continues Integration (CI) and continuous deployment (CD) capabilities and many other features directly in your repository.

In this article, we are going to look at the core concepts of Github Actions.

Why care about Github Actions?

Before we get into the technical detail let’s discussed why developers should care about Github Actions in the first place and which benefits they provide.

Build into Github:

Github Actions is fully integrated into Github and therefore doesn’t require and external site. This means that it can be managed in the same place as all your other repository related features like pull requests and issues.

Multi-container testing:

Actions allow you to test multi-container setups by adding support for Docker and docker-compose files to your workflow.

Multiple CI templates:

Github provides multiple templates for all kinds of CI (Continous Integration) configurations which make it extremely easy to get started. You can also create your own templates which you can then publish as an Action on the Github Marketplace.

Great free plan:

Actions are completely free for every open-source repository and include 2000 free build minutes per month for all your private repositories which is comparable with most CI/CD free plans. If that is not enough for your needs you can pick another plan or go the self-hosted route.

Core concepts

Below is a list of the core concepts used in Github Actions that you should be familiar with when using it or reading the documentation.

Actions:

Actions are the smallest portable building block of a workflow and can be combined as steps to create a job. You can create your own Actions or use publicly shared Actions from the Marketplace.

Event:

Events are specific activities that trigger a workflow run. For example, a workflow is triggered when somebody pushes to the repository or when a pull request is created. Events can also be configured to listen to external events using Webhooks.

Runner:

A runner is a machine with the Github Actions runner application installed. Then runner waits for available jobs it can then execute. After picking up a job they run the job’s actions and report the progress and results back to Github. Runners can be hosted on Github or self-hosted on your own machines/servers.

Job:

A job is made up of multiple steps and runs in an instance of the virtual environment. Jobs can run independently of each other or sequential if the current job depends on the previous job to be successful.

Step:

A step is a set of tasks that can be executed by a job. Steps can run commands or actions.

Workflow:

A Workflow is an automated process that is made up of one or multiple jobs and can be triggered by an event. Workflows are defined using a YAML file in the .github/workflows directory.

Using starter workflows

GitHub provides starter workflows for a variety of languages and tooling.

About starter workflows

GitHub offers starter workflows for a variety of languages and tooling. When you set up workflows in your repository, GitHub analyzes the code in your repository and recommends workflows based on the language and framework in your repository. For example, if you use Node.js, GitHub will suggest a starter workflow file that installs your Node.js packages and runs your tests. You can search and filter to find relevant starter workflows.

GitHub provides ready-to-use starter workflows for the following high level categories:

• Deployment (CD). For more information, see “About continuous deployment.”
• Security. For more information, see “Setting up code scanning using starter workflows.”
• Continuous Integration (CI). For more information, see “About continuous integration.”
• Automation. Automation starter workflows offer solutions for automating workflows, such as triaging pull requests and applying a label based on the paths that are modified in the pull request, or greeting users who are first time contributors to the repository.

You can also create your own starter workflow to share with your organization. These starter workflows will appear alongside the GitHub-provided starter workflows. For more information, see “Creating starter workflows for your organization.”

Using starter workflows

Anyone with write permission to a repository can set up GitHub Actions starter workflows for CI/CD or other automation.

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click  Actions.
3. If you already have a workflow in your repository, click New workflow.
4. Find the starter workflow that you want to use, then click Set up this workflow. To help you find the starter workflow that you want, you can search for keywords or filter by category.
5. If the starter workflow contains comments detailing additional setup steps, follow these steps. Many of the starter workflow have corresponding guides. For more information, see the GitHub Actions guides.”
6. Some starter workflows use secrets. For example, ${{ secrets.npm_token }}. If the starter workflow uses a secret, store the value described in the secret name as a secret in your repository. For more information, see “Encrypted secrets.”
7. Optionally, make additional changes. For example, you might want to change the value of on to change when the workflow runs.
8. Click Start commit.
9. Write a commit message and decide whether to commit directly to the default branch or to open a pull request.