Primer on GitHub Actions

  • With GitHub Actions one can build end-to-end continuous integration (CI) and continuous deployment (CD) capabilities.
  • Workflows run in Linux, macOS, Windows, and containers on GitHub-hosted machines, called runners.
  • One can also host their own runners to run workflows on machines they own or manage. Their runner machine would connect to GitHub using the open-source GitHub Actions self-hosted runner application.


  • Job execution time, up to 6 hours per run
  • Workflow run time, up to 72 hours per run
  • API requests, up to 1000 API requests in an hour across all actions within a repository
  • Concurrent jobs, 20 on the free plan


  • Free for public repositories
  • For private repositories, each GitHub account receives certain amount of free minutes and storage. 500 MB of storage, and 2000 minutes per month at the time of writing. Minutes reset every month, while storage usage does not.
  • Default spending limit of $0 to prevent accidental overage

Creating a workflow file

  1. At the root of the repository, create a directory named .github/workflows to store your workflow files.
  2. In the .github/workflows directory add a .yml file for the workflow specification.
  3. Use the Workflow syntax for GitHub Actions to define the workflow.
  4. Commit changes in the workflow file to the branch where one wants the workflow to run.


name: Greet Everyone
# This workflow is triggered on pushes to the repository.
on: [push]

    # Job name is Greeting
    name: Greeting
    # This job runs on Linux
    runs-on: ubuntu-latest
      # This step uses GitHub's hello-world-javascript-action:
      - name: Hello world
        uses: actions/hello-world-javascript-action@v1
          who-to-greet: 'Mona the Octocat'
        id: hello
      # This step prints an output (time) from the previous step's action.
      - name: Echo the greeting's time
        run: echo 'The time was ${{ steps.hello.outputs.time }}.'

Core Concepts

Individual tasks that are combined as steps to create a job. Actions are the smallest portable building block of a workflow. One can create their own actions, use actions shared from the GitHub community or mix and match the two.

Files created when you build and test your code. For example, might include binary or package files, test results etc. Artifacts are associated with the workflow run where they were created and can be used by another job or deployed.

A specific activity that triggers a workflow run.

A set of steps that execute on the same runner. One can define the dependency rules for how jobs run in a workflow file. Jobs can run at the same time in parallel or run sequentially depending on the status of a previous job.

An individual task that can run commands or actions. A job configures one or more steps. Each step in a job executes on the same runner, allowing the actions in that job to share information using the filesystem.

Virtual environment
GitHub hosts Windows Server 2019 and Ubuntu 18.04 runners on Standard_DS2_v2 virtual machines in Microsoft Azure with the GitHub Actions runner applications installed. The GitHub-hosted runner application is a fork of the Azure Pipelines Agent. GitHub uses MacStadium to host the macOS Catalina 10.15 runners.

Each virtual machine has a 2-core CPU, 7 GB of RAM and 14 GB of SSD disk space.

A configurable automated process that you can set up in your repository to build, test, package, release or deploy any project on GitHub. Workflows are made up of one or more jobs.

Workflow file
The YAML file that defines one’s workflow configuration with at least one job. This file lives in the root of one’s GitHub repository in the .github/workflows directory.

Workflow run
An instance of one’s workflow that runs when the pre-configured event occurs. One can see the jobs, actions, logs, and statuses for each workflow run.