Skip to content
/ act Public
forked from nektos/act

Run your GitHub Actions locally πŸš€

License

Notifications You must be signed in to change notification settings

fauxbytes/act

Β 
Β 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

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

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)

MacPorts package

sudo port install act

Chocolatey (Windows)

choco-shield

choco install act-cli

Scoop (Windows)

scoop-shield

scoop install act

AUR (Linux)

aur-shield

yay -Syu act

COPR (Linux)

dnf copr enable rubemlrm/act-cli
dnf install act-cli

Nix (Linux/macOS)

Nix recipe

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

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

# 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.

Flags

  -a, --actor string                                user that triggered the event (default "nektos/act")
      --replace-ghe-action-with-github-com          If you are using GitHub Enterprise Server and allow specified actions from GitHub (github.com), you can set actions on this. (e.g. --replace-ghe-action-with-github-com=github/super-linter)
      --replace-ghe-action-token-with-github-com    If you are using replace-ghe-action-with-github-com and you want to use private actions on GitHub, you have to set personal access token
      --artifact-server-path string                 Defines the path where the artifact server stores uploads and retrieves downloads from. If not specified the artifact server will not start.
      --artifact-server-port string                 Defines the port where the artifact server listens (will only bind to localhost). (default "34567")
  -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-cap-add stringArray               kernel capabilities to add to the workflow containers (e.g. --container-cap-add SYS_PTRACE)
      --container-cap-drop stringArray              kernel capabilities to remove from the workflow containers (e.g. --container-cap-drop SYS_PTRACE)
      --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
      --rebuild                                     rebuild local action docker image(s) even if already present
  -r, --reuse                                       don't remove container(s) on successfully completed workflow(s) to maintain state between runs
      --rm                                          automatically remove container(s)/volume(s) after a workflow(s) failure
  -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/")

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:

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

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.

Known Issues

Services

Services are not currently supported but are being worked on. See: #173

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/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.

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

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 😱***

Use an alternative runner image

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

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 jobs

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

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. You cannot use this method in job level if conditions, see Skipping jobs

- 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 pull_request -e pull-request.json

Act will properly provide github.head_ref and github.base_ref to the action as expected.

Pass Inputs to Manually Triggered Workflows

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 }}!"

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

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

About

Run your GitHub Actions locally πŸš€

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Go 97.8%
  • Shell 1.7%
  • Other 0.5%