Just this week I tried giving this another chance to debug some weird CI failures for ruby tests. I’m on M-series macs so there is an inherent platform mismatch. That coupled with us using depot images as action runners. I was never able to get it running past the dry-run stage. There is just a lot of differences between CI runners and my local docker images. I even gave the image from catthehacker a try. Which is like >15GB. It still wouldn’t run. Finally gave up.

Every mention of Github Actions is an occasion to start looking for the best alternative in <current_month>, let's go!

Is Dagger usable yet? Is there still hope for Earthly? Are general purpose workflow systems winning any time soon, or are we still afraid of writing code? Any new systems out there that cover all the totally basic features like running locally, unlike Github Actions?

Rather than tying CI & deployments to Github Actions, it is usually better to pull as much of it as possible out to shell scripts and call them in containers in GH actions..

There are optimizations you’ll want (caching downloaded dependencies etc); if you wait to make those after your build is CI-agnostic you’ll be less tempted by vendor specific shortcuts.

Usually means more code - but, easier to test locally. Also, swapping providers later will be difficult but not “spin up a team and spend 6 months” level.

In my experience (and as reflected by the comments on this post already), trying to run complex CI workflow locally is a fairly hopeless enterprise. If you have a fully containerized workflow, you might be able to get close, but even then ensuring you have all of your CI specific environment variables is often not a trivial task, and if your workflow orchestrates things across tasks (e.g. one task uploads an artifact and another task uses that artifact) you'll have a hard time reproducing exactly what is happening in CI. My company (RWX) builds a GitHub Actions competitor and we intentionally do not support local execution -- instead we focused on making it easy to kick off remote builds from your local machine without having to do a `git push` and we made it easy to grab an SSH session before, during, or after a running task to inspect things in the exact build environment that your workflow is running.

It's important to note that this tool does not use the same container images or runtime environment that GitHub Actions actually runs. It's an approximation.

For simple use cases that won't matter, but if you have complex GitHub Actions you're bound to find varying behavior. That can lead to frustration when you're debugging bizarre CI failures.

GitHub really needs to support local development with GitHub actions. Sheesh. What a step backwards.

WARNING: act is great if you use docker. Act does not support podman.

Issues or discussions related to providing support/coverage/compatibility/workarounds for podman are closed with a terse message. Unusual for an open source project.

Dumb question, but why hasn’t GitHub made a solution that lets you run GitHub Actions locally? Or at the very least a solution that validates the action (giving a bit more certainty that it will succeed, a bit like a dry-run)?

(My war story:) I stopped using GHAs after an optimistic attempt to save myself five key strokes ‘r’ ‘s’ ‘p’ ‘e’ ‘c’ led to 40+ commits and seeing the sunrise but still no successful test run via GHA. Headless browsers can be fragile but the cost benefit ratio against using GHA was horrible, at least for an indy dev.

Last time I looked at it, Act was a lot like the “serverless offline” options out there that try to mimic AWS services. If your use case is straightforward then I might work but if you do anything “exotic” (often the types of things I’m trying to debug in a failed run) Act doesn’t fully replicate the GHA experience.

Also, understandably, there is no macOS support and I use macOS on GHA for iOS builds (another place I have to debug that this wouldn’t cover).

What are some recommended alternatives for act, if any?

I’ve been a long time user, but I’ve run into tons of problems with act over the last year and am wondering if there are better alternatives out there.

I’ve been bedeviled by arm/intel/Mac issues with this.

I want to be able to use this project, I really do. But it’s just not yet there, and this isn’t on Nektos. Nektos is, as best I understand it, trying to approximate GHA, but it’s not easy.

I try to do as much as possible in a (dagger) script and use the GHA to call it. That way I can test the script locally.

I wonder if there is a proposal to support code-based actions. Config-based CI needs to die.

like a lot of folks i found nektos lacking. instead, i focused on keeping the gha workflows really light and putting any complexity in Task (taskfile.dev)—that way the meat of the workflows can be run locally, and the gha syntax is just the glue.

it works out very well.

It's amazing that Microsoft built a whole IDE and programming environment for builds but left all the debugging tools up to the community.

Lots of changes have to be made to your github action workflow to actually make this work properly.

I've had the displeasure of working with Macs on which we wrote code that would end up being a docker container. But what is compiled on a Mac is an aarch64 container. What is compiled on an AMD64 Linux machine is amd64.

This is annoying when the code you write is native or reaches out to native stuff. Then all of the sudden your container that builds perfectly on the Mac doesn't build on Linux anymore. (and vice versa, looking at you gcc on debian).

GitHub just (January) got Linux ARM runners, but they're not available for private customers yet.

And their Mac runners do not come with Docker, and it cannot be installed.

I've been using this recently but there's many issues, and things that can only be tested remotely. In some cases I've had to guard steps if: ${{ !env.ACT }} so they don't run locally.

I use this for work - but there are edge cases all over the place that I keep running into (e.g. Yarn being installed on Github-hosted runners, but not self-hosted ones or act - https://github.com/actions/setup-node/issues/182)

Apart from that it's been quite good!

I'm convinced that the only way is to do the reverse. Make the Github actions just be a thin wrapper over docker-compose invocations.

I think this is really cool. We're tackling this problem from the other side by building `pixi` (pixi.sh) which bundles project / package management with a task runner so that any CI should be as simple as `pixi run test` and easy to execute locally or in the cloud.

I would love for this to actually work, but apart from trivial workflows, it never replaced the dreaded game of CI ping/pong.

My alternative was to have a dedicated repository where I can spam the Git and workflow run histories as much as I need to experiment with workflows.

I've wanted this so much! My main questions are about permissions. I use environment-specific variables and secrets, I would need to reconfigure them locally and didn't see how. The other issue is workload identity federation.

Back in the day we called that a shell script. We had this tool called Jenkins that would run the shell script in a new folder every time you pushed a change to gitlab. It was pretty neat.

I'm using this to run on a risc-v board I have at home, it's pretty nice.

My action just calls `make build test` but it is convenient to have it hooked to GH for automated testing on PRs

anyone have any tips for testing actions locally, rather than workflows?

Despite the name, act is really only for the latter. You can try to test a local action by putting it in a workflow and calling that, but if you do a checkout in your workflow that will overwrite the mount of your local code into the act container, meaning you’ll get the version from the remote branch instead. Depending on the action, you may not be able to comment out the checkout step while testing.

This didn't work for me. I found just running Ubuntu in VirtualBox was close enough for my use case.

`act`is great, but it's still annoying dealing with secrets!

Anyone use kubernetes argo workflow for CI automation?

wow this is a popular project^_^

Which GitHub Actions context variables are emulated or customizable in act, like github.event, github.actor, or secrets

We have come full circle

act is a great helper tool for another tool that is an utter shit.

Ive given up on gh actions a while ago and transitioned to bash scripts in docker containers. I can reproduce stuff locally, can test it, can debug it, etc.

I dont get how GH Actions do not yet have a tool that looks and works like jupyter workbook. Then it would have been fantastic.

If CI/CD tools were code editors, then Jenkins/JFrog would be like Vi/Vim—powerful and traditional. GitLab CI would resemble Helix or Zed, offering a modern and efficient approach. Meanwhile, GitHub Actions would be akin to VSCode, but with a touch of Dreamweaver CC, blending user-friendly features with comprehensive capabilities.