Need help with act?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

nektos
18.4K Stars 485 Forks MIT License 455 Commits 73 Opened issues

Description

Run your GitHub Actions locally 🚀

Services available

!
?

Need anything else?

Contributors list

act-logo

Overview push Join the chat at https://gitter.im/nektos/act Go Report Card awesome-runners

"Think globally,

act
locally"

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 sample repo!

Demo

Installation

Necessary prerequisites for running
act

act
depends on
docker
to run workflows.

If you are using macOS, please be sure to follow the steps outlined in Docker Docs for how to install Docker Desktop for Mac.

If you are using Windows, please follow steps for installing Docker Desktop on Windows.

If you are using Linux, you will need to install Docker Engine.

act
is currently not supported with
podman
or other container backends (it might work, but it's not guaranteed). Please see #303 for updates.

Installation through package managers

Homebrew (Linux/macOS)

homebrew version

brew install act

MacPorts (macOS)

sudo port install act

Chocolatey (Windows)

choco-shield

choco install act-cli

Scoop (Windows)

scoop-shield

scoop install act

AUR (Linux)

aur-shield

yay -S act

Nix (Linux/macOS)

Nix recipe

Global install:

nix-env -iA nixpkgs.act

or through

nix-shell
:
nix-shell -p act

Go (Linux/Windows/macOS/any other platform supported by Go)

If you have Go 1.16+, you can install latest released version of

act
directly from source by running:
go install github.com/nektos/[email protected]

or if you want to install latest unreleased version:

go install github.com/nektos/[email protected]

If you want a smaller binary size, run above commands with

-ldflags="-s -w"
go install -ldflags="-s -w" github.com/nektos/[email protected]

Other install options

Bash script

Run this command in your terminal:

curl 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

# Command structure:
act [] [options]
If no event name passed, will default to "on: push"

List the actions for the default event:

act -l

List the actions for a specific event:

act workflow_dispatch -l

Run the default (push) event:

act

Run a specific event:

act pull_request

Run a specific job:

act -j test

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.

Flags

  -a, --actor string                     user that triggered the event (default "nektos/act")
  -b, --bind                             bind working directory to container, rather than copy
      --container-architecture string    Architecture which should be used to run containers, e.g.: linux/amd64. If not specified, will use host default architecture. Requires Docker server API Version 1.41+. Ignored on earlier Docker server platforms.
      --container-daemon-socket string   Path to Docker daemon socket which will be mounted to containers (default "/var/run/docker.sock")
      --defaultbranch string             the name of the main branch
      --detect-event                     Use first event type from workflow as event that triggered the workflow
  -C, --directory string                 working directory (default ".")
  -n, --dryrun                           dryrun mode
      --env stringArray                  env to make available to actions with optional value (e.g. --env myenv=foo or --env myenv)
      --env-file string                  environment file to read and use as env in the containers (default ".env")
  -e, --eventpath string                 path to event JSON file
      --github-instance string           GitHub instance to use. Don't use this if you are not using GitHub Enterprise Server. (default "github.com")
  -g, --graph                            draw workflows
  -h, --help                             help for act
      --insecure-secrets                 NOT RECOMMENDED! Doesn't hide secrets while printing logs.
  -j, --job string                       run job
  -l, --list                             list workflows
      --no-recurse                       Flag to disable running workflows from subdirectories of specified path in '--workflows'/'-W' flag
  -P, --platform stringArray             custom image to use per platform (e.g. -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04)
      --privileged                       use privileged mode
  -p, --pull                             pull docker image(s) even if already present
  -q, --quiet                            disable logging of output from steps
  -r, --reuse                            reuse action containers to maintain state
  -s, --secret stringArray               secret to make available to actions with optional value (e.g. -s mysecret=foo or -s mysecret)
      --secret-file string               file with list of secrets to read from (e.g. --secret-file .secrets) (default ".secrets")
      --use-gitignore                    Controls whether paths specified in .gitignore should be copied into container (default true)
      --userns string                    user namespace to use
  -v, --verbose                          verbose output
  -w, --watch                            watch the contents of the local repo and run when files change
  -W, --workflows string                 path to workflow file(s) (default "./.github/workflows/")

In case you want to pass a value for

${{ github.token }}
, you should pass
GITHUB_TOKEN
as secret:
act -s GITHUB_TOKEN=[insert token or leave blank for secure input]
.

Known Issues

MODULE_NOT_FOUND

A

MODULE_NOT_FOUND
during
docker cp
command #228 can happen if you are relying on local changes that have not been pushed. This can get triggered if the action is using a path, like:
- name: test action locally
  uses: ./

In this case, you must use

actions/[email protected]
with a path that has the same name as your repository. If your repository is called my-action, then your checkout step would look like:
steps:
  - name: Checkout
    uses: actions/[email protected]
    with:
      path: "my-action"

If the

path:
value doesn't match the name of the repository, a
MODULE_NOT_FOUND
will be thrown.

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:
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:

| GitHub Runner | Micro Docker Image | Medium Docker Image | Large Docker Image | | --------------- | ------------------------------ | --------------------------------------------------------- | ---------------------------------------------------------- | |

ubuntu-latest
|
node:12-buster-slim
|
ghcr.io/catthehacker/ubuntu:act-latest
|
ghcr.io/catthehacker/ubuntu:full-latest
| |
ubuntu-20.04
|
node:12-buster-slim
|
ghcr.io/catthehacker/ubuntu:act-20.04
|
ghcr.io/catthehacker/ubuntu:full-20.04
| |
ubuntu-18.04
|
node:12-buster-slim
|
ghcr.io/catthehacker/ubuntu:act-18.04
|
ghcr.io/catthehacker/ubuntu:full-18.04
|

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: :elephant:

*** WARNING - this image is >18GB 😱***

Use an alternative runner image

To use a different image for the runner, use the

-P
option.
act -P =

If your workflow uses

ubuntu-18.04
, consider below line as an example for changing Docker image used to run that workflow:
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
act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04 -P ubuntu-latest=ubuntu:latest -P ubuntu-16.04=node:12-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:
# 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:
act --env-file my.env

.env
:
MY_ENV_VAR=MY_ENV_VAR_VALUE
MY_2ND_ENV_VAR="my 2nd env var value"

Skipping steps

Act adds a special environment variable

ACT
that can be used to skip a step that you don't want to run locally. E.g. a step that posts a Slack message or bumps a version number.
- name: Some step
  if: ${{ !env.ACT }}
  run: |
    ...

Events

Every GitHub event is accompanied by a payload. You can provide these events in JSON format with the

--eventpath
to simulate specific GitHub events kicking off an action. For example:
{
  "pull_request": {
    "head": {
      "ref": "sample-head-ref"
    },
    "base": {
      "ref": "sample-base-ref"
    }
  }
}
act -e pull-request.json

Act will properly provide

github.head_ref
and
github.base_ref
to the action as expected.

GitHub Enterprise

Act supports using and authenticating against private GitHub Enterprise servers. To use your custom GHE server, set the CLI flag

--github-instance
to your hostname (e.g.
github.company.com
).

Please note that if your GHE server requires authentication, we will use the secret provided via

GITHUB_TOKEN
.

Please also see the official documentation for GitHub actions on GHE for more information on how to use actions.

Support

Need help? Ask on Gitter!

Contributing

Want to contribute to act? Awesome! Check out the contributing guidelines to get involved.

Manually building from source

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.