"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 useact
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 yourMakefile
!
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!
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.
Homebrew (Linux/macOS)
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):
brew install act --HEAD
MacPorts (macOS)
sudo port install act
Chocolatey (Windows)
choco install act-cli
Scoop (Windows)
scoop install act
Winget (Windows)
winget install nektos.act
AUR (Linux)
yay -Syu act
COPR (Linux)
dnf copr enable rubemlrm/act-cli
dnf install act-cli
Nix (Linux/macOS)
Global install:
nix-env -iA nixpkgs.act
or through nix-shell
:
nix-shell -p act
Using the latest Nix command, you can run directly :
nix run nixpkgs#act
Act can be installed as a GitHub CLI extension:
gh extension install https://github.com/nektos/gh-act
Run this command in your terminal:
curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash
Download the latest release and add the path to your binary into your PATH.
# 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
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 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:
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
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.
Services are not currently supported but are being worked on. See: #173
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/checkout@v2
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/checkout@v2
with:
path: "my-action"
If the path:
value doesn't match the name of the repository, a MODULE_NOT_FOUND
will be thrown.
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}}')
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:16-buster-slim |
catthehacker/ubuntu:act-latest |
catthehacker/ubuntu:full-latest |
ubuntu-22.04 |
node:16-bullseye-slim |
catthehacker/ubuntu:act-22.04 |
unavailable |
ubuntu-20.04 |
node:16-buster-slim |
catthehacker/ubuntu:act-20.04 |
catthehacker/ubuntu:full-20.04 |
ubuntu-18.04 |
node:16-buster-slim |
catthehacker/ubuntu:act-18.04 |
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
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
)
If you need an environment that works just like the corresponding GitHub runner then consider using an image provided by nektos/act-environments:
nektos/act-environments-ubuntu:18.04
- built from the Packer file GitHub uses in actions/virtual-environments.
*** WARNING - this image is >18GB π±***
catthehacker/ubuntu:full-*
- built from Packer template provided by GitHub, see catthehacker/virtual-environments-fork or catthehacker/docker_images for more information
To use a different image for the runner, use the -P
option.
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:
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:16-buster-slim
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
- usesomevalue
as the value forMY_SECRET
.act -s MY_SECRET
- check for an environment variable namedMY_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 frommy.secrets
file.- secrets file format is the same as
.env
format
- secrets file format is the same as
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"
You cannot use the env
context in job level if conditions, but you can add a custom event property to the github
context. You can use this method also on step level if conditions.
on: push
jobs:
deploy:
if: ${{ !github.event.act }} # skip during local actions testing
runs-on: ubuntu-latest
steps:
- run: exit 0
And use this event.json
file with act otherwise the Job will run:
{
"act": true
}
Run act like
act -e event.json
Hint: you can add / append -e event.json
as a line into ./.actrc
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.
You cannot use this method in job level if conditions, see Skipping jobs
- name: Some step
if: ${{ !env.ACT }}
run: |
...
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 pull_request -e pull-request.json
Act will properly provide github.head_ref
and github.base_ref
to the action as expected.
Example workflow file
on:
workflow_dispatch:
inputs:
NAME:
description: "A random input name for the workflow"
type: string
SOME_VALUE:
description: "Some other input to pass"
type: string
jobs:
test:
name: Test
runs-on: ubuntu-latest
steps:
- name: Test with inputs
run: |
echo "Hello ${{ github.event.inputs.NAME }} and ${{ github.event.inputs.SOME_VALUE }}!"
act --input NAME=somevalue
- usesomevalue
as the value forNAME
input.act --input-file my.input
- load input values frommy.input
file.- input file format is the same as
.env
format
- input file format is the same as
Example JSON payload file conveniently named payload.json
{
"inputs": {
"NAME": "Manual Workflow",
"SOME_VALUE": "ABC"
}
}
Command for triggering the workflow
act workflow_dispatch -e payload.json
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.
Need help? Ask on Gitter!
Want to contribute to act? Awesome! Check out the contributing guidelines to get involved.
- Install Go tools 1.18+ - (https://golang.org/doc/install)
- Clone this repo
git clone [email protected]:nektos/act.git
- Run unit tests with
make test
- Build and install:
make install