Running Github Actions On Local Machine.

Saurabh Kadam
Geek Culture
Published in
4 min readJul 6, 2021

Github Action is one heck of the CI, but you want to create a new CI/CD pipeline in Github. The only way to test is the making push or pull requests to the respective repository.

Source: GOOGLE

What if I tell you there is one more way to test run Github actions.

https://github.com/nektos/act is one of the solutions for testing your pipeline on local for syntax fix or even fixing script before pushing to Github.

For Mac, it is a straightforward install.

brew install act

It will download and install the dependencies for the local run. To use it in a repository, clone the repo on the local machine

Once it is installed, go to the root directory. We can start experimenting with stuff like total steps in the workflow. I have only step workflow to show which GitHub provides. So it is showing as stage 0.

$ act -l
ID Stage Name
test 0 testbuild 0 build

the act is the command used to run the workflow. It will ask for the image that you want to use to run the workflow. Please choose an image as per your requirement. More details are mentioned in that repo’s README.

act? Please choose the default image you want to use with act:- Large size image: +20GB Docker image, includes almost all tools used on GitHub Actions (IMPORTANT: currently only ubuntu-18.04 platform is available)- Medium size image: ~500MB, includes only necessary tools to bootstrap actions and aims to be compatible with all actions- Micro size image: <200MB, contains only NodeJS required to bootstrap actions, doesn't work with all actionsDefault image and other options can be changed manually in ~/.actrc (please refer to https://github.com/nektos/act#configuration for additional information about file structure) Medium

For help, it is command act-h

Usage:act [event name to run]If no event name passed, will default to "on: push" [flags]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-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-r, --reuse                            reuse action containers to maintain state--rm                               automatically remove containers just before exit-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--version                          version for act-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/")

To run the workflow as a dry run, it is act-n. The successful output looks like this.

To run the workflow, you just need the act command. it would work like this.

Succesful scenario

What if there is a failure in the script? It can show the same in the run. I purposefully changed some variables in the script.

Failure Scenario

This is an awesome tool while developing CI/CD pipelines scripts on the local machines. Just give it a try.

--

--

Saurabh Kadam
Geek Culture

Devops Professional by Job.Machine Learning ,Deep learning and 3D modelling for Hobby.