nektos / act Goto Github PK

Hi!

Thanks for the project, it helps a lot to debug issues and all that! Its awesome!

So, yesterday we had that github outage in which webhook weren't being delivered. I thought it would be a great idea to use act to deploy locally in these situations, but... my workflows have a tag filtering step, and seems like act always uses master.

Would you be interested in something to hack around that? In theory, just walk on files on .git/refs/tags and check if the contents of any of them match .git/HEAD contents and glue it together with act.

I'm working on a hacky-ish implementation BTW :)

As of this afternoon, when running the example gcloud auth workflow (https://github.com/actions/gcloud/tree/master/auth#example-workflow-file), with the errors fixed, I get an error about not being able to clone the repo. Maybe a temporary github error?

$ GCLOUD_AUTH=$(base64 ~/gcloud.json) act
WARN[0000] unable to get git revision: open /Users/paulbellamy/temp/act-test/.git/refs/heads/master: no such file or directory
WARN[0000] unable to get git repo: section 'remote "origin"' does not exist
[setup-google-cloud] git clone 'https://github.com/actions/gcloud' # ref=master
[setup-google-cloud] Unable to pull refs/heads/master: empty git-upload-pack given
[setup-google-cloud] Unable to resolve master: reference not found
Error: reference not found

The first 2 errors are because it is not a real repo, just a minimal test-case directory I created.

Attached is a tarball of a failing repo. Any info would be super helpful, thanks! Love the project, btw.

act-test.tar.gz

This got me stumped for a while:

[Spec tests] docker build -t php-action:3d6545d /home/xen/dev/acdc/.github/actions/php-action
[Unit tests] docker run image=php-action:3d6545d entrypoint=["./vendor/bin/phpunit"] cmd=["--testsuite" "Unit"]
Error: Error: No such image: php-action:3d6545d

Until running act with -v told me that the build failed due to errors in the Dockerfile. Act v 0.1.0.

firstly, thanks for this amazing tool! absolutely love it and it's making my iteration speed so much faster.

I have an action which runs fine locally using act, but fails when executed by github due to (it seems) a file permission error.

My dockerfile is very simple:

FROM alekzonder/puppeteer
ADD puppeteer-config.json /app
RUN npm install mermaid.cli
ENTRYPOINT ["/app/node_modules/.bin/mmdc", "-p", "/app/puppeteer-config.json"]
CMD ["--help"]

my action looks like this:

action "mermaid" {
uses = "./action-mermaid"
args = "-i gantt.mmd -o gantt-tmp.png -w 1884 -H 450"
}

this runs absolutely fine if I do act mermaid, but on github I get an error writing to the file:

Error: EACCES: permission denied, open 'gantt-tmp.png'

However, I've created a ticket with GitHub support since this may just be a bug on their end. The same issue exists if I direct the output to an absolute path like /github/home/gantt-tmp.png, /github/workspace/gantt-tmp.png , and it doens't matter whether the output file exists or not.

workflow action looks like:

action "docker-login" {
  uses = "docker://docker"
  runs = ["sh", "-c", "echo $DOCKER_AUTH | docker login --username $REGISTRY_USER --password-stdin"]
  secrets = ["DOCKER_AUTH"]
  env = {
    REGISTRY_USER = "jess"
  }
}

I get

$ act -l
Error: At 8:10: root.Action.docker-login.Runs: unknown type for string *ast.ListType

Maybe it's the pipe or env variable, haven't dug in yet :)

I have this error when I try to run act in example repo:

Error: Error response from daemon: client version 1.39 is too new. Maximum supported API version is 1.38

OS: Ubuntu 18.04
Docker: Docker version 18.06.1-ce, build e68fc7a

First off, let me just say that this is totally amazing and I'm using the heck out of it!

Okay, now the bug report: the GITHUB_REPOSITORY environment variable value isn't correct inside of act. It appears to be set to the git remote URL, but it should be just the owner + repo slug: nektos/act, as opposed to https://github.com/nektos/act or git+ssh://[email protected]/nektos/act.git.

I also noticed that it's not possible to override the "automatic" environment variables (GITHUB_) in the workflow file, so you have to work around this in code by parsing the URL. Allowing the automatic variables to be overridden (even though they can't be in Actions) would be super helpful if this turns out to be a tricky issue to fix. ✌️

When act fails to build a docker image (for whatever reason) it should print out some error and bail, instead of resuming the run.

act pull_request
[build] docker build -t pull-request-action:874ac47 /Users/sosedoff/Experiments/test-action/pull-request-action
[build] docker run image=pull-request-action:874ac47 entrypoint=[] cmd=[]
Error: Error: No such image: pull-request-action:874ac47

I can see the docker build error with act -v pull_request:

DEBU[0000] Loading revision from git directory '/Users/sosedoff/Experiments/test-action/.git'
DEBU[0000] HEAD points to 'refs/heads/pr1'
DEBU[0000] Found revision: 874ac47e39077f506a73ceb0dea94b4eb51d5770
DEBU[0000] Writing entry to tarball workflow/event.json len:2
[build] docker build -t pull-request-action:874ac47 /Users/sosedoff/Experiments/test-action/pull-request-action
[build] Building image from '/Users/sosedoff/Experiments/test-action/pull-request-action'
DEBU[0000] Creating archive for build context dir '/Users/sosedoff/Experiments/test-action/pull-request-action' with relative dockerfile 'Dockerfile'
[build] Creating image from context dir '/Users/sosedoff/Experiments/test-action/pull-request-action' with tag 'pull-request-action:874ac47'
[build] Step 1/2 : FROM alpine:slim
[build]
[build] manifest for alpine:slim not found
[build] docker run image=pull-request-action:874ac47 entrypoint=[] cmd=[]
DEBU[0000] Error: No such image: pull-request-action:874ac47
DEBU[0000] Error: No such image: pull-request-action:874ac47
Error: Error: No such image: pull-request-action:874ac47

👋 Hey @cplee and @nektos team!

Opening this issue to ask: any plans to introduce automated testing for this project (through a GitHub Action or a third-party CI service)?

[Feature tests] Building image from '/home/xen/dev/acdc/.github/actions/php-action'
[Spec tests] Building image from '/home/xen/dev/acdc/.github/actions/php-action'
DEBU[0003] Creating archive for build context dir '/home/xen/dev/acdc/.github/actions/php-action' with relative dockerfile 'Dockerfile' 
[Unit tests] Building image from '/home/xen/dev/acdc/.github/actions/php-action'
DEBU[0003] Creating archive for build context dir '/home/xen/dev/acdc/.github/actions/php-action' with relative dockerfile 'Dockerfile' 
[Feature tests] Creating image from context dir '/home/xen/dev/acdc/.github/actions/php-action' with tag 'php-action:de6d421'
[Unit tests] Creating image from context dir '/home/xen/dev/acdc/.github/actions/php-action' with tag 'php-action:de6d421'
DEBU[0003] Creating archive for build context dir '/home/xen/dev/acdc/.github/actions/php-action' with relative dockerfile 'Dockerfile' 
[Spec tests] Creating image from context dir '/home/xen/dev/acdc/.github/actions/php-action' with tag 'php-action:de6d421'

Not so much a problem when the image has been built, but if one changes the action, it starts the build process three times.

act interprets Branch names (the @master portion in uses = "/abc/def@master") as case insensitive, which differs from GitHub.

This results in different behavior between local and GitHub environment.

Any Repository/Action should be fine for testing, but for the sake of completeness:

• Create an action as described in this README.md
• run the action -> success
• change the case in uses = "jakobgalbavy/github-actions/slack-message@master" to @Master and run the action -> succeeds locally, fails on GitHub

I have an action that runs on a schedule.

act fails to run if it's present in the main.workflow file.

Example output:

Error: unable to parse and validate
  Line 21: Workflow `WORKFLOW' has unknown `on' value `schedule(0 9 * * *)'
  Line 133: Workflow `WORKFLOW2' has unknown `on' value `schedule(0 16 * * 2)'

Following this documentation for chrons:
https://developer.github.com/actions/managing-workflows/creating-and-cancelling-a-workflow/#scheduling-a-workflow

I can remove these for testing and add them back, but thought I would raise an issue.

Thanks for making this tool!

It looks like the use of .github/main.workflow is deprecated now that actions are moving to YAML. It'd be nice to support the new format as my newer repos with Actions does not create main.workflow anymore.

Currently, action logs are sent to stderr, which is the default for logrus. It would be better if action logs were sent to stdout and only error messages sent to stderr.

Is act available as a docker image?

I have a project which creates local *.so on compilation.
These are never git commited (naturally). They appear to be gitignored because of a system (default?) .gitignore.

It would be good if act could similarly respect any local or global/default .gitignores.

Otherwise, this can lead to thorny problems, in this case, a bad ELF header.

Perhaps act should simply commit whatever is on the working tree as a first step, maybe in a tempdir and run from there.
By relying on the local git add/commit we'd automatically respect whatever .gitignore action was in place

Currently, act will include the entire working directory in the container it builds (which does make sense in the context of a cloned repository, but not necessarily a local working copy).

For example, I may have dependencies built for my host operating system (MacOS), but they need to be rebuilt inside the container. This works fine in Actions in production because the dependencies aren't checked into the repository. However, I can't see a way of not sending them to the built container with act without rming them (which slows down local development on my host).

Perhaps there could be some sort of .ignore file that ignores files from the host, and also prevents those files from the container from being copied back to the host?

There are several docker actions which are forbidden on Github actions. See: https://github.com/actions/docker/issues/7

Being able to enforce the same locally would make debugging workflows easier.
But, given there's no list of which actions are forbidden, it might be tricky to enforce the same locally.

Thanks for this project @nektos, it's a super useful tool.

It worked great for me for a while, but now I'm getting Unhandled rejection Error: ENOSPC: no space left on device errors when my npm ci action runs.

I added df -h to my workflow file to see what's going on, and it shows I've used 100% of space in /github/home:

But doing an ls -a in that dir shows it's empty. I've cleared every cache I can think of, removed node_modules before install, and ran docker system prune -af, but still get the error.

I asked the Actions folks and they think it might be related to act, since I only get the error locally and not when running the workflow in a PR.

Thanks for any advice!

I noticed that github actions are run using the following container: gcr.io/github-actions-images/action-runner

• https://console.cloud.google.com/gcr/images/github-actions-images/GLOBAL/action-runner?gcrImageListsize=30

$ docker run gcr.io/github-actions-images/action-runner:latest --help
Usage of action-runner:
  -action-id string
    	Unique identifier for action execution
  -debug
    	Indicates whether to output Debug logs
  -entrypoint string
    	Overwrite the default ENTRYPOINT of the image
  -env-keys string
    	Specifies which environment variables to copy to container (defaults to all)
  -forward-mount value
    	Mount paths to forward
  -image string
    	Which image to run
  -reporting-url string
    	URL to report progress
  -secret-keys string
    	Environment variable keys to filter from output (comma-separated
  -signing-key string
    	Path to signing key
  -working-dir string
    	Working directory for container

Here's an example run on github:

• https://github.com/cedrickring/golang-action/runs/74951453

It might be useful to keep in sync local functionality by matching what the real github actions uses.

it appears that even when the working tree is unclean, act sets the GITHUB_SHA env var to whatever the last git commit on that branch was.

This seems friendly, but can lead to some pretty unexpected behavior, because AFAIK act actually runs with the unclean working tree, so the GITHUB_SHA is actually kind of wrong.

In any kind of situation where you're referencing something via GITHUB_SHA this can get weird (e.g. I am FROM:ing Docker images in the version of the GITHUB_SHA).

I think it would be safer behavior to either:

• don't set a GITHUB_SHA when the working tree is unclean
• do not allow act to run on an unclean working tree (safest of them all maybe, because that's how github actions actually works, it never runs on unclean trees).

I have a workflow that is run for each pull request where several actions may comment on that pull request. Obviously, when running locally with act there is no pull-request, and therefore nowhere to comment to.

My current workaround is to set the comments_url to https://httpstat.us/200 (or run a local http-echo container and point to that), but it would be nice if we had a better way.

The README states that you can run a specific action with the -t flag:

# Run a specific action:
act -t test

The actual flag looks to be -a, --action.

Usage:
  act [event name to run] [flags]

Flags:
  -a, --action string      run action
  -C, --directory string   working directory (default ".")
  -n, --dryrun             dryrun mode
  -f, --file string        path to workflow file (default "./.github/main.workflow")
  -h, --help               help for act
  -l, --list               list actions
  -v, --verbose            verbose output
      --version            version for act

When testing actions locally, if your password is a token or certificate string then the action aborts:

$ act 
Provide value for 'CERTIFICATE_AUTHORITY': *********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************
2019/03/20 16:36:38 abort

This is mostly due to an issue here - as the gopass does not support multi-byte characters! But this prevents local testing where secret is bigger string as is the case here.

It would be great to be able to provide some sort of .env file to avoid prompting user each time you run a workflow.

I'm playing around with an action that runs when a PR is created, however with act command i'm getting this error (running act):

Error: unsupported event: push

Example workflow file:

workflow "test" {
  on = "pull_request"
  resolves = ["build"]
}

action "build" {
  uses = "./pull-request-action"
}

Im not sure why the error refers to push event

👋 @cplee –– thank you for creating this project! ✨

A workflow file containing an action whose args specify a REGEX will throw a "panic:unquote err: invalid syntax" error.

Looking at previously reported issues, #4 was the most similar report raised for this kind of error.

example.workflow file

workflow "New workflow" {
  on = "push"
  resolves = ["filter-version-before-deploy"]
}

action "filter-version-before-deploy" {
  uses = "actions/bin/filter@master"
  args = "tag v?[0-9]+\\.[0-9]+\\.[0-9]+"
}

Running act -l on this file with verbose output enabled

act -f example.workflow -lv
DEBU[0000] Setting working dir to /path/to/repo/.github 
DEBU[0000] Loading workflow config from /path/to/repo/.github/example.workflow 
DEBU[0000] Parsed literal "tag v?[0-9]+\\.[0-9]+\\.[0-9]+" to list ["tag" "v?[0-9]+\\.[0-9]+\\.[0-9]+"] 
panic: unquote "v?[0-9]+\.[0-9]+\.[0-9]+" err: invalid syntax

goroutine 1 [running]:
github.com/hashicorp/hcl/hcl/token.Token.Value(0x9, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc000020300, 0x1a, 0x0, 0x105060d, ...)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/hcl/token/token.go:162 +0x59e
github.com/hashicorp/hcl.(*decoder).decodeString(0xc0001efa60, 0xc0000281b0, 0x30, 0x1810040, 0xc0000587e0, 0x165a9c0, 0xc00004c850, 0x198, 0x0, 0xc0001ee2f0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:530 +0x2c5
github.com/hashicorp/hcl.(*decoder).decode(0xc0001efa60, 0xc0000281b0, 0x30, 0x1810040, 0xc0000587e0, 0x165a9c0, 0xc00004c850, 0x198, 0x0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:106 +0x7e5
github.com/hashicorp/hcl.(*decoder).decodeSlice(0xc0001efa60, 0xc000028150, 0x2d, 0x1810000, 0xc000316230, 0x16508a0, 0xc0003221c0, 0x197, 0xc0001ee568, 0xc0001ee568)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:459 +0x46d
github.com/hashicorp/hcl.(*decoder).decode(0xc0001efa60, 0xc000028150, 0x2d, 0x1810000, 0xc000316230, 0x16508a0, 0xc0003221c0, 0x197, 0x0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:104 +0x881
github.com/hashicorp/hcl.(*decoder).decodeStruct(0xc0001efa60, 0xc0000280f0, 0x28, 0x1810100, 0xc000058540, 0x1717ca0, 0xc000322180, 0x199, 0x0, 0xc0001eeda0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:702 +0x1536
github.com/hashicorp/hcl.(*decoder).decode(0xc0001efa60, 0xc0000280f0, 0x28, 0x1810140, 0xc000058540, 0x1717ca0, 0xc000322180, 0x199, 0x0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:108 +0x749
github.com/hashicorp/hcl.(*decoder).decodeMap(0xc0001efa60, 0xc000022280, 0xb, 0x1810100, 0xc00000a6a0, 0x1686900, 0xc00001c278, 0x195, 0xc0001ef1b8, 0xc0001ef1b8)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:386 +0x696
github.com/hashicorp/hcl.(*decoder).decode(0xc0001efa60, 0xc000022280, 0xb, 0x1810100, 0xc00000a6a0, 0x1686900, 0xc00001c278, 0x195, 0x0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:100 +0x5f3
github.com/hashicorp/hcl.(*decoder).decodeStruct(0xc0001efa60, 0x175b303, 0x4, 0x1810100, 0xc00000a1a0, 0x170e280, 0xc00001c240, 0x199, 0x0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:692 +0x1749
github.com/hashicorp/hcl.(*decoder).decode(0xc0001efa60, 0x175b303, 0x4, 0x1810100, 0xc00000a1a0, 0x170e280, 0xc00001c240, 0x199, 0x0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:108 +0x749
github.com/hashicorp/hcl.DecodeObject(0x17149a0, 0xc00001c240, 0x1810100, 0xc00000a1a0, 0xc00000a1a0, 0x0)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/hashicorp/hcl@v1.0.0/decoder.go:60 +0x16d
github.com/nektos/act/actions.parseWorkflowsFile(0x180e000, 0xc00000c030, 0xc00000c030, 0x0, 0x0)
	/Users/casey.lee/Dev/personal/act/actions/parser.go:68 +0x166
github.com/nektos/act/actions.ParseWorkflows(0xc000024180, 0x39, 0xc0000261e0, 0x4a, 0xc000314000, 0xc0001efc18, 0x15e1d13, 0xc000314000)
	/Users/casey.lee/Dev/personal/act/actions/parser.go:35 +0x1f9
github.com/nektos/act/cmd.newRunAction.func1(0xc000312000, 0xc00031a0c0, 0x0, 0x3, 0x0, 0x0)
	/Users/casey.lee/Dev/personal/act/cmd/root.go:53 +0xae
github.com/spf13/cobra.(*Command).execute(0xc000312000, 0xc000084090, 0x3, 0x3, 0xc000312000, 0xc000084090)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:762 +0x473
github.com/spf13/cobra.(*Command).ExecuteC(0xc000312000, 0x1, 0x1760e3c, 0x11)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:852 +0x2fd
github.com/spf13/cobra.(*Command).Execute(0xc000312000, 0x1cab590, 0x175cf78)
	/Users/casey.lee/Dev/go/pkg/mod/github.com/spf13/cobra@v0.0.3/command.go:800 +0x2b
github.com/nektos/act/cmd.Execute(0x1814b40, 0xc0001f5880, 0x1807a90, 0x5)
	/Users/casey.lee/Dev/personal/act/cmd/root.go:41 +0x423
main.main()
	/Users/casey.lee/Dev/personal/act/main.go:33 +0x167

While I don't have a complete understanding for how things really work under the hood, I see that the parsed literal is logged in parseCommand:

parseCommand is called in this block:

Steps to reproduce

1. Use some workflow with 3 actions, one local, several remote, like so:

workflow "Test Action" {
  on = "push",
  resolves = ["Shellcheck", "Test dependency installation"]
}

action "Shellcheck" {
  uses = "actions/bin/shellcheck@1b3c130914f7b20890bf159306137d994a4c39d0"
  args = "*.sh"
}

action "Install Dependencies" {
  uses = "./"
}

action "Test dependency installation" {
  uses = "maxheld83/ghactions_check@master"
  args = "testthat::test_dir(path = \"tests/testthat/\", stop_on_failure = TRUE)"
  needs = "Install Dependencies"
}

2. run act. Everything works as intended.

3. git commit git push to the third action "maxheld83/ghactions_check@master"

4. run act again.

Observed behavior

act uses the old, now outdated version of "maxheld83/ghactions_check@master" and does not float to the latest commit of master.

Expected behavior:

act should always use the latest commit to master; this is how github actions behaves.

Fix

Hardcoding a commit "maxheld83/ghactions_check@78652ea60553d2fd92d256876cd2873264cb9233" solves the problem, but defeats the purpose.

Hunch

maybe a caching problem?

By default containers are run using the default user (usually root), which may produce files or artifacts owned by root. Instead we should run the containers under the current user (command line equivalent would be --user $(id -u)).

It didn't work with the new yaml syntax (https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions).

When running act -f .github/workflows/main.yml -l, I got:

Error: unable to parse
  Line 1: illegal char

I noticed remote Docker support was more or less fixed somewhere after #5, but it does not seem to work for hosts that I connect to over SSH. Since Docker 18.09 there's been support to use docker -H ssh://me@server. Is there any way that could work with this project as well?

Error I get for reference:

Error: error during connect: Post http://alex%40192.168.xx.xx/v1.39/images/create?fromImage=node&tag=11.6.0: dial tcp: lookup [email protected]: no such host

macOS 10.13.6 (17G5019)
sample repo from README: https://github.com/cplee/github-actions-demo

act version: 0.0.5
platform: OSX 10.14.2

When referencing actions that are contained in sub directories of the same repo. i.e.:

action "Lint" {
uses = "./.github/actions/go"
args = "lint"
}

the act parser allows you to write the uses clause without "./" at the start like this:

action "Lint" {
uses = ".github/actions/go"
args = "lint"
}

Although this is very correct and will run locally, the GitHub action parser won't be as permissive and will emit a parser error when you push your code

Behaviors should be aligned...

Error response from daemon: client version 1.39 is too new. Maximum supported API version is 1.37

GitHub requires that all values to environment variables be strings—not, for example, integers. Act will heppily accept integers, however.

Here is an example workflow that act will execute, but that GitHub will reject:

workflow "Launch the rescue mission" {
  on = "release"
  resolves = ["debug"]
}

action "debug" {
  uses = "actions/bin/debug"
  env = {
    ENV_VAR = 1
    }
}

GitHub, on the other hand, requires something like

workflow "Launch the rescue mission" {
  on = "release"
  resolves = ["debug"]
}

action "debug" {
  uses = "actions/bin/debug"
  env = {
    ENV_VAR = "1"
    }
}

(notice the "1" in quotes)

This simple tuning can lead to at least 30% gain in action execution time, up to twice faster than without it 😉

if runtime.GOOS == "darwin" {
    // add `:delegated` at the end of the workspace volume string
    // see https://docs.docker.com/docker-for-mac/osxfs-caching/#tuning-with-consistent-cached-and-delegated-configurations
}

https://github.com/ant-design/ant-design

Do you have any plans for allowing users to provide a custom event.json file?

When act runs with some git action in the root, it appears to set a new nektos/act user in the .git/config.
That makes a ton of sense.

However, it'd be nice if act could clean up after itself, and revert this change on success or failure, so that I don't muck up my git config.

I think this "problem" only happens in the relatively rare situation where you're running some git actions directly in your root.
An example would be (as in my case) when I deploy to GitHub pages from the root: said action then git inits stuff right in my repo root, locally, thus overwriting/amending my own .git/config.

I just commited a bunch of stuff and was really surprised that I had somehow become nektos/act 😸.

This software is phenomenal, thanks for the generous work @nektos!

(this is somewhat related to #28 I think?)

it appears that currently, act cannot deal with multi-workflow setups (i.e. >1 workflow statements with on = "push"), though these are supported by GitHub Actions.

Here's an (unfortunately not minimal) example:

workflow "Build and Check" {
  on = "push"
  resolves = [
    "Check Package",
    "Build Website"
  ]
}

workflow "Deploy" {
  on = "push"
  resolves = [
    "Upload Cache",
    "Code Coverage",
    "Deploy Website"
  ]
}

action "GCP Authenticate" {
  uses = "actions/gcloud/auth@04d0abbbe1c98d2d4bc19dc76bcb7754492292b0"
  secrets = [
    "GCLOUD_AUTH"
  ]
}

action "Download Cache" {
  uses = "actions/gcloud/cli@d124d4b82701480dc29e68bb73a87cfb2ce0b469"
  runs = "gsutil -m cp -r gs://ghactions-cache/lib.tar.gz /github/home/"
  needs = [
    "GCP Authenticate"
  ]
}

action "Decompress Cache" {
  uses = "actions/bin/sh@5968b3a61ecdca99746eddfdc3b3aab7dc39ea31"
  runs = "tar -zxf /github/home/lib.tar.gz --directory /github/home"
  needs = [
    "Download Cache"
  ]
}

action "Install Dependencies" {
  uses = "./actions/install-deps"
  needs = [
    "Decompress Cache"
  ]
}

action "Compress Cache" {
  uses = "actions/bin/sh@5968b3a61ecdca99746eddfdc3b3aab7dc39ea31"
  runs = "tar -zcf lib.tar.gz --directory /github/home lib"
  needs = [
    "Install Dependencies"
  ]
}

action "Upload Cache" {
  uses = "actions/gcloud/cli@d124d4b82701480dc29e68bb73a87cfb2ce0b469"
  runs = "gsutil -m cp lib.tar.gz gs://ghactions-cache/"
  needs = [
    "Compress Cache",
    "Filter Not Act"
  ]
}

action "Build Package" {
  uses = "./actions/build"
  needs = [
    "Install Dependencies"
  ]
}

action "Filter Not Act" {
  uses = "actions/bin/filter@3c0b4f0e63ea54ea5df2914b4fabf383368cd0da"
  args = "not actor nektos/act"
}

action "Code Coverage" {
  uses = "./actions/covr"
  needs = [
    "Check Package",
    "Filter Not Act"
  ]
  secrets = [
    "CODECOV_TOKEN"
  ]
}

action "Check Package" {
  uses = "./actions/check"
  needs = [
    "Build Package"
  ]
}

action "Install Package" {
  uses = "./actions/install"
  needs = [
    "Build Package"
  ]
}

action "Build Website" {
  uses = "./actions/pkgdown"
  needs = [
    "Install Package"
  ]
}

action "Master Branch" {
  uses = "actions/bin/filter@c6471707d308175c57dfe91963406ef205837dbd"
  needs = [
    "Check Package", 
    "Build Website"
  ]
  args = "branch master"
}

action "Deploy Website" {
  uses = "maxheld83/[email protected]"
  env = {
    BUILD_DIR = "docs"
  }
  secrets = ["GH_PAT"]
  needs = [
    "Master Branch",
    "Filter Not Act"
  ]
}

On act, this fails both workflows pretty soon with error: exit with NEUTRAL: 78, even though only one of the workflows even includes any kind of filter action.

This presumably imperfect parsing of the main.workflow is also (?) reflected in act -l output:

                    ╔═════════════╗
                    ║ EVENT: push ║
                    ╚═════════════╝
                           ⬇
        ╭──────────────────╮ ╭────────────────╮
        │ GCP Authenticate │ │ Filter Not Act │
        ╰──────────────────╯ ╰────────────────╯
                           ⬇
                   ╭────────────────╮
                   │ Download Cache │
                   ╰────────────────╯
                           ⬇
                  ╭──────────────────╮
                  │ Decompress Cache │
                  ╰──────────────────╯
                           ⬇
                ╭──────────────────────╮
                │ Install Dependencies │
                ╰──────────────────────╯
                           ⬇
          ╭───────────────╮ ╭────────────────╮
          │ Build Package │ │ Compress Cache │
          ╰───────────────╯ ╰────────────────╯
                           ⬇
 ╭─────────────────╮ ╭──────────────╮ ╭───────────────╮
 │ Install Package │ │ Upload Cache │ │ Check Package │
 ╰─────────────────╯ ╰──────────────╯ ╰───────────────╯
                           ⬇
          ╭───────────────╮ ╭───────────────╮
          │ Build Website │ │ Code Coverage │
          ╰───────────────╯ ╰───────────────╯
                           ⬇
                   ╭───────────────╮
                   │ Master Branch │
                   ╰───────────────╯
                           ⬇
                   ╭────────────────╮
                   │ Deploy Website │
                   ╰────────────────╯
                    ╔═════════════╗
                    ║ EVENT: push ║
                    ╚═════════════╝
                           ⬇
        ╭────────────────╮ ╭──────────────────╮
        │ Filter Not Act │ │ GCP Authenticate │
        ╰────────────────╯ ╰──────────────────╯
                           ⬇
                   ╭────────────────╮
                   │ Download Cache │
                   ╰────────────────╯
                           ⬇
                  ╭──────────────────╮
                  │ Decompress Cache │
                  ╰──────────────────╯
                           ⬇
                ╭──────────────────────╮
                │ Install Dependencies │
                ╰──────────────────────╯
                           ⬇
          ╭────────────────╮ ╭───────────────╮
          │ Compress Cache │ │ Build Package │
          ╰────────────────╯ ╰───────────────╯
                           ⬇
 ╭─────────────────╮ ╭───────────────╮ ╭──────────────╮
 │ Install Package │ │ Check Package │ │ Upload Cache │
 ╰─────────────────╯ ╰───────────────╯ ╰──────────────╯
                           ⬇
          ╭───────────────╮ ╭───────────────╮
          │ Build Website │ │ Code Coverage │
          ╰───────────────╯ ╰───────────────╯
                           ⬇
                   ╭───────────────╮
                   │ Master Branch │
                   ╰───────────────╯
                           ⬇
                   ╭────────────────╮
                   │ Deploy Website │
                   ╰────────────────╯

Apparently, act here mushes the two workflows together.

Currently act binds the local repo as /github/workspace in the containers for the actions. The problem is that any mutations that the actions make to the workspace affect the local repo.

We should add support for a new flag -t to instruct act to create a copy of the local repo in a new temp directory and bind that temp directory into the containers so that act can be run in a way that guarantees no changes are made on the local repo.

It would be nice if the default event payloads reflected the example ones provided on developer.github.com. I've pulled together the current set here: https://github.com/mcolyer/actions-toolkit-action/tree/master/fixtures.

I still think it's helpful to have a flag to override the payload (ie -e), as sometimes you want to change a specific payload but I figured a default would be helpful.

Just to keep track of the work here :)

Thanks for you awesome tool !

In actions, GITHUB_SHA is a string with no whitespace. When running a workflow via act, the GITHUB_SHA has a trailing newline attached to it.

Hi,

To work around infuriating Docker performance issues on macOS (Mojave) which have been unaddressed for more than a year, I use https://github.com/codekitchen/dinghy to work around it.

Unfortunately, act doesn't seem to abide DOCKER_HOST, DOCKER_CERT_PATH, DOCKER_TLS_VERIFY, DOCKER_MACHINE_NAME, etc.

Any chance this could be made to work?

This is absolutely bananas amazing work @nektos.

GitHub Actions documentation seems to recommend that we point to specific commits when relying on external actions from other repos:

If you are developing an action for other people to use, GitHub recommends keeping the action in its own repository instead of bundling it with other application code. This allows you to version, track, and release the action just like any other software. Storing an action in its own repository makes it easier for the GitHub community to discover the action, narrows the scope of the code base for developers fixing issues and extending the action, and decouples the action's versioning from the versioning of other application code.

Consequently, the default GitHub Action for Docker hard codes the latest commit into my main.workflow:

action "GitHub Action for Docker-1" {
  uses = "actions/docker/cli@c08a5fc9e0286844156fefff2c141072048141f6"
  args = "build --tag=foo:bar ."
}

This seems quite attractive to me, and in keeping with the whole deployment-as-software-paradigm, because it isolates me from potentially breaking changes in the upstream action.

However, act doesn't seem to like this:

act
[GitHub Action for Docker-1] git clone 'https://github.com/actions/docker'
Error: reference not found

On a hunch, I deleted the hard-coded commit from the main.workflow, and voila, act does its thing.

action "GitHub Action for Docker-1" {
  uses = "actions/docker/cli
  args = "build --tag=foo:bar ."
}

act

Perhaps something is wrong in how the main.workflow gets parsed?

Let me know if you need a tighter reproducible example.

First of all, thanks a lot for the project. It is super useful.

It seems like act clone is not bringing in the branches. My workflow is to create a branch on my actions repo, and test it from another project, before it lands on master.

The error is the following:

[setup dependencies] git clone 'https://github.com/bltavares/actions' # ref=bash
[setup dependencies]   cloning https://github.com/bltavares/actions to /var/folders/3l/gmb8fzc51qsg2mf4426vn80c0000gn/T/act/bltavares/actions/bash@bash
[setup dependencies] Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.ts:  14% (1/7)
Compressing objects: 100% (7/7), done.ts:  14% (1/7)
[setup dependencies] Total 1435 (delta 0), reused 5 (delta 0), pack-reused 1428
[setup dependencies] Cloned https://github.com/bltavares/actions to /var/folders/3l/gmb8fzc51qsg2mf4426vn80c0000gn/T/act/bltavares/actions/bash@bash
[setup dependencies] Unable to resolve bash: reference not found
DEBU[0002] reference not found

After I run git fetch && git checkout on the repo used to clone it worked, with an warning:

[setup dependencies] git clone 'https://github.com/bltavares/actions' # ref=bash
[setup dependencies] Unable to pull refs/heads/bash: non-fast-forward update

Example workflow

workflow "validate PRs" {
  on = "push"
  resolves = ["setup dependencies"]
}

action "setup dependencies" {
  uses = "bltavares/actions/bash@bash"
  args = ["echo 1"]
}

I might be able to check it at some point, but I'm not able to do this on the following weeks.

You can use short SHAs like this:

action "run tests" {
  uses = "actions/docker/cli@04185cf"
  args = "build ."
}

This works fine in Github, but it does not using act:

[run tests] Unable to resolve 04185cf: reference not found
Error: reference not found

Is it possible for an action to reference an image in a "uses" variable that is a Docker format (docker://namespace/image:tag), and have act use the image that's already in the local docker image cache?

At first look in the code, and trying this, it appears that if the uses is set to a docker:// format, act will always invoke a DockerPullExecutor, which will update the image to the version that's in the registry, not the locally built one.

Hey guys, as GitHub announced the new syntax for workflow, is there an expectation of act to support this as well?

Github Action YAML