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.
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.
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.
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!
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.
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
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.
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.
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.
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.
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.
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.
Just wanted to share that the Build your own Interpreters challenge on CodeCrafters is based on the Crafting Interpreters book and is free at the moment.
It sure does.
One chinese person driving a gas vehicle, shouldn't be blamed over Taylor Swift taking a thousand trips on her jet just because he is from China.
Everybody needs to pitch in.
It’s not about blame, and we will never get everyone even in single countries to “pitch in,” much less have the world working together. That’s a children’s fantasy.
The world the west is confronted with is this: Chinese and Indians want to live like Americans. The legitimacy of the government in places like China and Bangladesh rest on being able to deliver 6-8% GDP growth every year. They won’t do anything to jeopardize that, and we can’t control what they do. So carbon capture is going to have to be a pillar of any climate mitigation strategy.
I just have one request, can you add a proper export feature ? Maybe as a json. Your current export from the 'All transactions' page, then 'Share' doesn't include the payment account.
Hi! Share feature is intended to be used just in scope of Transaction, it's not a month report. It's like to show to friend how its debt was formed. But thanks for feedback, I will think how to add it properly.
Currently it supports ledger and hledger natively. If your file is compatible with any of the two, it would work.
There is a clear separation between the cmd line tool and paisa. It should be relatively straightforward to add support for more. I will look into it later.
