[HN Gopher] Run your GitHub Actions locally
       ___________________________________________________________________
        
       Run your GitHub Actions locally
        
       Author : flashblaze
       Score  : 121 points
       Date   : 2025-05-16 08:55 UTC (3 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | igor47 wrote:
       | 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.
        
         | GuinansEyebrows wrote:
         | could you just source vars from an .env file? maybe a bit more
         | work to get the secrets pulled down. i guess ideally you'd want
         | to be able to pull those values directly from github as an
         | option (including secrets) if that's your primary source of
         | truth.
        
         | jlongman wrote:
         | Secrets can be loaded from a file.
         | 
         | https://nektosact.com/usage/index.html?highlight=Secret#secr...
        
       | iotapi322 wrote:
       | Lots of changes have to be made to your github action workflow to
       | actually make this work properly.
        
         | mytydev wrote:
         | What things have you needed to change? Can't say I've ever
         | needed to do that but of course I've only used it on a few
         | projects.
        
           | jlongman wrote:
           | In GitHub we use an OIDC token to access some AWS resources.
           | Locally I need to populate tokens etc and so I have an `if:
           | ${{ACT}}` and a not condition to populate it.
        
       | ryangg wrote:
       | 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.
        
         | jlongman wrote:
         | It's even worse than that, it's 20GB compressed and 60GB
         | uncompressed. Regardless, if your VM runs out of disk space
         | there's no meaningful error (well 12 months ago) except a
         | failure to start. (Possibly colima-specific I dunno I
         | uninstalled docker-docker)
         | 
         | I do find that some things just work locally and fail in real
         | actions and vice versa. For the most part it's made it easier
         | to move the bar forward though.
        
         | suryao wrote:
         | Something like this may help by letting you ssh into the
         | running instance so you can debug with the exact context:
         | https://docs.warpbuild.com/tools/action-debugger
        
         | larusso wrote:
         | I had luck with my actions I tried to debug. But I also had the
         | issue that the runtime difference is simply too big to 100%
         | trust it. Too bad because I think the tool is quite good.
        
         | Ameo wrote:
         | Sounds similar to my own experiences trying to debug GH actions
         | locally.
         | 
         | I've tried twice now to get it working, pulling down many GBs
         | of images and installing stuff and then getting stuck in some
         | obscure configuration or environment issue. I was even running
         | Linux locally which I figured would be the happiest path.
         | 
         | I'm not eager to try again, and unless there's a CI that's very
         | slow or GH actions that need to be updated often for some
         | reason, I feel like it's better to just brute-force it -
         | waiting for CI to run remotely.
        
       | tagraves wrote:
       | 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.
        
       | pydry wrote:
       | It's amazing that Microsoft built a whole IDE and programming
       | environment for builds but left all the debugging tools up to the
       | community.
        
         | mdaniel wrote:
         | You don't get vendor lock in if you're able to run GHA _on any
         | compute you 'd like_ (yes, I'm aware of self-hosted runners,
         | and even that their Packer code is open source. That doesn't
         | make it _easy_ to use GHA outside of github.com)
        
       | brianhorakh wrote:
       | 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.
        
         | organsnyder wrote:
         | There's a long-open issue[1] for Podman support. Maybe they're
         | just tired of dups?
         | 
         | [1] https://github.com/nektos/act/issues/303
        
       | joshstrange wrote:
       | 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).
        
       | arclight_ wrote:
       | 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.
        
         | plumeria wrote:
         | AWS Lambda publishes Docker images (e.g.
         | public.ecr.aws/lambda/python:3.12-arm64), does Github Actions
         | have something similar?
        
           | esafak wrote:
           | https://github.com/actions/runner-images
        
       | ElijahLynn wrote:
       | GitHub really needs to support local development with GitHub
       | actions. Sheesh. What a step backwards.
        
         | joshdavham wrote:
         | > GitHub really needs to support local development with GitHub
         | actions.
         | 
         | Agreed. I'm thankful for tools like act, but there really
         | should be an officially supported way to run gh actions
         | locally.
        
       | badmonster wrote:
       | wow this is a popular project^_^
       | 
       | Which GitHub Actions context variables are emulated or
       | customizable in act, like github.event, github.actor, or secrets
        
       | paulryanrogers wrote:
       | This didn't work for me. I found just running Ubuntu in
       | VirtualBox was close enough for my use case.
        
       | franky47 wrote:
       | 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.
        
       | droelf wrote:
       | 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.
        
       | 2OEH8eoCRo0 wrote:
       | We have come full circle
        
       | samgranieri wrote:
       | 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.
        
         | jt_b wrote:
         | I've seen (but not used) this tool recently, which seems like
         | it does a similar thing. Curious if it is any better
         | experience.
         | 
         | https://github.com/bahdotsh/wrkflw
        
       | esafak wrote:
       | 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.
        
         | spion wrote:
         | Why dagger and not just... any language? (Nushell for example
         | https://www.nushell.sh/)
        
           | esafak wrote:
           | Because I'm typically building and running tests in
           | containers in CI, which is what dagger is for.
        
         | mikepurvis wrote:
         | Yup. Every time there's one of these threads I renew my call
         | for GHA to have hooks where in-band build tools like nix,
         | bazel, dagger, and friends can propagate upward optimal
         | information to be displayed in the web gui, in particular
         | annotations and info about multiple tasks that run in parallel
         | or series.
        
       | joshdavham wrote:
       | 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.
        
       | claytonjy wrote:
       | 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.
        
       | Daviey wrote:
       | `act`is great, but it's still annoying dealing with secrets!
        
       | cyberax wrote:
       | 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.
        
       | notnmeyer wrote:
       | 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.
        
       | Kinrany wrote:
       | 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?
        
         | manx wrote:
         | I think we could build something on top of nix that is as easy
         | to use and powerful as earthly, but gets all the nice stuff
         | from nix: reproducibility, caching, just use any command from
         | any nix package, etc
        
       | eYrKEC2 wrote:
       | Anyone use kubernetes argo workflow for CI automation?
        
       ___________________________________________________________________
       (page generated 2025-05-19 23:00 UTC)