Post

Run your GitHub Actions locally

Why would you want to do this? Two reasons:

  • Fast Feedback - Rather than having to commit/push every time you want to test out the changes you are making to your .github/workflows/ files (or for any changes to embedded GitHub actions), you can use act to run the actions locally. The environment variables and filesystem are all configured to match what GitHub provides.
  • Local Task Runner - I love make. However, I also hate repeating myself. With act, you can use the GitHub Actions defined in your .github/workflows/ to replace your Makefile!

How Does It Work?

When you run act it reads in your GitHub Actions from .github/workflows/ and determines the set of actions that need to be run. It uses the Docker API to either pull or build the necessary images, as defined in your workflow files and finally determines the execution path based on the dependencies that were defined. Once it has the execution path, it then uses the Docker API to run containers for each action based on the images prepared earlier. The environment variables and filesystem are all configured to match what GitHub provides.

Let’s see it in action with a simple demo

Demo

Act User Guide

Please look at the act user guide for more documentation.

Installation

act depends on docker to run workflows.

Homebrew (macOS)

1
brew install act

or if you want to install version based on latest commit, you can run below (it requires compiler to be installed but Homebrew will suggest you how to install it, if you don’t have it):

1
brew install act --HEAD

Installation as GitHub CLI extension

Act can be installed as a GitHub CLI extension:

1
gh extension install https://github.com/nektos/gh-act

Other install options

Bash script

Run this command in your terminal:

1
curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

Manual download

Download the latest release and add the path to your binary into your PATH.

Example commands

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Command structure:
act [<event>] [options]
If no event name passed, will default to "on: push"
If actions handles only one event it will be used as default instead of "on: push"

# List all actions for all events:
act -l

# List the actions for a specific event:
act workflow_dispatch -l

# List the actions for a specific job:
act -j test -l

# Run the default (`push`) event:
act

# Run a specific event:
act pull_request

# Run a specific job:
act -j test

# Collect artifacts to the /tmp/artifacts folder:
act --artifact-server-path /tmp/artifacts

# Run a job in a specific workflow (useful if you have duplicate job names)
act -j lint -W .github/workflows/checks.yml

# Run in dry-run mode:
act -n

# Enable verbose-logging (can be used with any of the above commands)
act -v

First act run

When running act for the first time, it will ask you to choose image to be used as default. It will save that information to ~/.actrc, please refer to Configuration for more information about .actrc and to Runners for information about used/available Docker images.

GITHUB_TOKEN

GitHub automatically provides a GITHUB_TOKEN secret when running workflows inside GitHub.

If your workflow depends on this token, you need to create a personal access token and pass it to act as a secret:

1
act -s GITHUB_TOKEN=[insert token or leave blank and omit equals for secure input]

If GitHub CLI is installed, the gh auth token command can be used to automatically pass the token to act

1
act -s GITHUB_TOKEN="$(gh auth token)"

WARNING: GITHUB_TOKEN will be logged in shell history if not inserted through secure input or (depending on your shell config) the command is prefixed with a whitespace.

Docker context support

The current docker context isn’t respected (#583).

You can work around this by setting DOCKER_HOST before running act, with e.g:

1
export DOCKER_HOST=$(docker context inspect --format '\{\{.Endpoints.docker.Host}}')

Runners

GitHub Actions offers managed virtual environments for running workflows. In order for act to run your workflows locally, it must run a container for the runner defined in your workflow file. Here are the images that act uses for each runner type and size:

Windows and macOS based platforms are currently unsupported and won’t work (see issue #97)

Please see IMAGES.md for more information about the Docker images that can be used with act

Default runners are intentionally incomplete

These default images do not contain all the tools that GitHub Actions offers by default in their runners. Many things can work improperly or not at all while running those image. Additionally, some software might still not work even if installed properly, since GitHub Actions are running in fully virtualized machines while act is using Docker containers (e.g. Docker does not support running systemd). In case of any problems please create issue in respective repository (issues with act in this repository, issues with nektos/act-environments-ubuntu:18.04 in nektos/act-environments and issues with any image from user catthehacker in catthehacker/docker_images)

Alternative runner images

If you need an environment that works just like the corresponding GitHub runner then consider using an image provided by nektos/act-environments:

⚠️ 🐘 *** WARNING - this image is >18GB 😱***

Using local runner images

The --pull flag is set to true by default due to a breaking on older default docker images. This would pull the docker image everytime act is executed.

Set --pull to false if a local docker image is needed

1
  act --pull=false

Use an alternative runner image

To use a different image for the runner, use the -P option.

1
act -P <platform>=<docker-image>

If your workflow uses ubuntu-18.04, consider below line as an example for changing Docker image used to run that workflow:

1
act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04

If you use multiple platforms in your workflow, you have to specify them to change which image is used. For example, if your workflow uses ubuntu-18.04, ubuntu-16.04 and ubuntu-latest, specify all platforms like below

1
act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04 -P ubuntu-latest=ubuntu:latest -P ubuntu-16.04=node:16-buster-slim

Secrets

To run act with secrets, you can enter them interactively, supply them as environment variables or load them from a file. The following options are available for providing secrets:

  • act -s MY_SECRET=somevalue - use somevalue as the value for MY_SECRET.
  • act -s MY_SECRET - check for an environment variable named MY_SECRET and use it if it exists. If the environment variable is not defined, prompt the user for a value.
  • act --secret-file my.secrets - load secrets values from my.secrets file.
    • secrets file format is the same as .env format

Configuration

You can provide default configuration flags to act by either creating a ./.actrc or a ~/.actrc file. Any flags in the files will be applied before any flags provided directly on the command line. For example, a file like below will always use the nektos/act-environments-ubuntu:18.04 image for the ubuntu-latest runner:

1
2
# sample .actrc file
-P ubuntu-latest=nektos/act-environments-ubuntu:18.04

Additionally, act supports loading environment variables from an .env file. The default is to look in the working directory for the file but can be overridden by:

1
act --env-file my.env

.env:

1
2
MY_ENV_VAR=MY_ENV_VAR_VALUE
MY_2ND_ENV_VAR="my 2nd env var value"
This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.