Unfortunately act is only capable of running very simple workflows. I've found this action to be more useful against the endless PR stream: https://github.com/mxschmitt/action-tmate
You drop it in your workflow and get an SSH shell into the worker, figure things out iteratively, then push when it's working.
Can you elaborate with some examples of workflows that it is incapable of?
So far I’ve not found any limitations or issues using Ubuntu runners on my OSX dev machine. A couple examples from my workflows:
- building docker images
- provisioning VMs with the Digital Ocean cli / http api
- hardening VMs with ansible
- creating/managing k3s clusters with k3sup
- deploying apps with helm
I like your suggested approach of using tmate to access the worker mid-way through a run. This should make it faster to develop/debug the steps that make up the workflow. Though this doesn’t address the cycle time of push-to-GitHub/queue-workflow/watch-for-result.
I’m actually going to try combining the two techniques - use tmate to develop inside a local act runner.
Workflows that interact with the Github API heavily will fail as they're not available in act e.g. actions like https://github.com/styfle/cancel-workflow-action. Dealing with secrets is also a bit cumbersome. You can throw the following on actions that are not compatible with act in order to skip them:
if: ${{ !env.ACT }}
That said, despite its limitations, I've been using both act and tmate in combination for a couple of years. Gets the job done.
You drop it in your workflow and get an SSH shell into the worker, figure things out iteratively, then push when it's working.