101–110 of 137 posts
GitHub really needs to support local development with GitHub actions. Sheesh. What a step backwards.
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?
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.
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 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
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?
Gitlab? It's been around longer than Actions, it's much better and honestly not sure why anyone would consider anything else (but happy to hear if there are reasons).
/me puts tinfoilhat
Earlier quoted context omitted.
Feel like the correct way to use any CI these days is to just have it do almost nothing. The CI just triggers a script. And then you can run that script locally.
exactly. I am surprised by the amount of comments in this and similar threads praying for github to add more complexity to an already over-complicated and fragile solution. CI must be local-first and platform-agnostic.
Earlier quoted context omitted.
exactly. I am surprised by the amount of comments in this and similar threads praying for github to add more complexity to an already over-complicated and fragile solution. CI must be local-first and platform-agnostic.
Because you may want caching, or to install certain software in the VM or container that you already have locally. Separating scripts could help, but IME the CI environment is always different enough that some branching or mimicking is needed to harmonize them.
Apart from that it's been quite good!
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!
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.
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…
I’m pretty sure GH actions don’t run the latest Ruby version.