[ryangg]

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.

[Ameo]

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.

[dcherman]

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.

[anner_]

https://github.com/namespacelabs/breakpoint

[dayjah]

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).

[90s_dev]

GH Actions have always worked flawlessly for me, as long as I don't ever do anything unusual.

Last week I moved from a custom server back to GH Pages + GH Actions, and broke a feature that depended on an out dir existing after one build phase and before another. I have no idea how to fix it. It's probably simple, I'm just burnt out.

[lukevp]

Each job runs on a separate runner. If you want to pass data across, use artifacts to upload and then retrieve the specified file(s).

[cedws]

You can pass outputs between jobs by declaring one job as a dependency of another with needs:, then reference that dependency's outputs with needs.<job>.outputs

[cedws]

ChristopherHX publishes Docker images which are created directly from packing up the root filesystem into a tarball from inside a runner. The images are huge though.

https://github.com/ChristopherHX/runner-image-blobs/pkgs/con...

[suryao]

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

[jlongman]

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.

[pxc]

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.

[philistine]

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.

[hk1337]

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.

[pseudocomposer]

Are there specific problems? I’ve been primarily Ruby at work the last 6 or so years (before, also doing Ruby, but also lots of Java, Kotlin, Swift, FE stuff, and some Python)… exactly that period… and haven’t really noticed any issues. Granted, I don’t typically use a lot of obscure binary-only dependencies, or things whose C/C++/machine code wouldn’t mostly cross-compile fine.

Granted, all this time I’ve always only used rbenv-managed Ruby versions (and rvm before that). I’ve long disliked/avoided Python because its ecosystem lacked any equivalent, but I know “uv” has gained popularity there, and perhaps Mise is good in Python land as well.

[hk1337]

Usually just errors building it. Mostly python but I think I had an error with 3.4.3 the other day.

[larusso]

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.