Live data from Hacker News

Run GitHub Actions locally

github.com

111–120 of 137 posts

Re: Run GitHub Actions locally

#111
post #5

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 li…

My experience with Ruby on Apple Silicon as been far from seamless. The only way I could thoroughly get rid of problems was by running the most recent Ruby release and dealing with what THAT causes. I’m pretty sure GH actions don’t run the latest Ruby version.

My experience with both Ruby and Python Apple Silicon has been hit or miss. Mise has made it a lot simpler and seamless but if you need an older version or the absolute latest when it is released, you might have some issues. Mise has helped a lot, I generally do not expect to get an error.

Re: Run GitHub Actions locally

#112
post #108

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!

Same experience here. Edge cases everywhere, though most can be worked around. You can specify different runners to use. The default images are a compromise to keep size down. There is a very large image that tries to include everything you might want. I would suggest trying that if you don’t mind the very large (15GB IIRC) image.

I definitely remember considering the larger images - I think we ended up not using them since my work's usecase for act is running user github workflows on-demand on temporary VMs. The hope was that most usage is covered by the smaller images - and in fairness that has been true so far.

Re: Run GitHub Actions locally

#113
post #5

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 li…

This is really only for debugging the logic of your Actions, isn't it?

On my team, Nix seems to work pretty well for encapsulating most of the interesting things CI jobs do. We don't use virtualization to run local versions of our jobs, and we don't run into architecture mismatch issues.

Re: Run GitHub Actions locally

#114
post #95
post #61

Earlier quoted context omitted.

How's Jenkins looking these days?

It's still a miserable experience to maintain it, update it, deal with mostly old plugins, dynamically loading the tooling, groovy idiosyncrasies.. and UI/UX that despite recent efforts continues to feel terrible. Managing the underlying infra is painful, and it remains a security liability even when not making obvious mistakes like exposing it to any open network. And good luck if you're having that fun at a windows…

>It's still a miserable experience to maintain it...

How so? I've been maintaining an instance for a decade, and it really doesn't seem that bad. Updating plugins we do about monthly, it's largely clicking a couple buttons in the UI. Updating Jenkins itself is an apt update. Groovy takes a bit to grok, sure, LLMs help a lot here. The UX isn't that bad, IMHO, but I can see why some would say that. We've switched over almost entirely to using a couple runners, docker, and Jenkinsfiles, which works great. We do still run deploys directly on the Jenkins box, largely because we need to run them single-threaded so they don't step on each-other with load balancer rotations.

Re: Run GitHub Actions locally

#115
post #42

Every mention of Github Actions is an occasion to start looking for the best alternative in , 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?

I think Earthly is dead, but Dagger seems to be healthy still...

Earthly was amazing. The exact same setup in CI and locally. They're reviving it with a community effort, but I'm not sure if it'll live

Re: Run GitHub Actions locally

#116
post #46
post #42

Every mention of Github Actions is an occasion to start looking for the best alternative in , 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?

earthly is config-based, so it's in the same league as GHA in my book. https://docs.earthly.dev/docs/earthly-config dagger is the only code-based solution. It works, but it does have some edges since it has a much bigger surface area and is constantly growing.

That's not really related... that config is machine specific, not really related to CI.

This is what Earthfiles look like: https://docs.earthly.dev/docs/earthfile

Re: Run GitHub Actions locally

#117
post #42

Every mention of Github Actions is an occasion to start looking for the best alternative in , 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?

Gitea can be easily self-hosted and supports Gitea Actions, which are largely compatible with GitHub Actions. I’m about to try it out. https://docs.gitea.com/next/usage/actions/overview

In the context of this submission, one will want to exercise caution because they and their forgejo friends are using forks of nektos/act, with all the caveats of both "act" and "fork"

https://gitea.com/gitea/act -> https://gitea.com/gitea/act_runner

https://code.forgejo.org/forgejo/act -> https://code.forgejo.org/forgejo/runner

Re: Run GitHub Actions locally

#118
post #101

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

I'm convinced that they specifically won't do that so that people won't use them to build competing products. Actions is one of the pieces that make GitHub money.

> Actions is one of the pieces that make GitHub money.

How do you figure that? I'd buy "lock people in the platform," but in that way GitHub Issues has been the moat for far longer than Actions has

Re: Run GitHub Actions locally

#119

Earlier quoted context omitted.

Match dev env to prod env?

No, as their MDM solution only works on Macs.

In fairness, the opposite way usually ends up being much cheaper: make prod run arm64

I would guess that just `alias docker="docker --platform=linux/amd64"` type thing would go a long way toward evicting those platform mismatches[1]. I would also guess there's a way to switch off the binfmt "helper" in colima such that trying to run arm64 in the VM would immediately puke rather than silently helping you

1: or, of course, don't push production containers from your workstation, but the years have taught me that I'm talking to myself

Re: Run GitHub Actions locally

#120
post #22

Earlier quoted context omitted.

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 upd…

There's another alternative - debug in CI itself. There's a few ways that you can pause your CI at a specific step and get a shell to do some debugging, usually via SSH. I've found that to be the most useful.

Came here to say this, and to recommend: https://github.com/appleboy/ssh-action

It’s slow and arduous work to inject at the right point and find out what went wrong. But it’s miles better than act. act is a noble idea, and I hope it can meet its target, but it falls short currently.

ssh-action gets you on the host, and lets you quickly establish what is happening and implement fixes. It’s top notch!

(I’m unaffiliated, just a big fan of ssh-action).

Post reply on HN