Would a tool like act help here? ( https://github.com/nektos/act ) I suppose orchestration that is hiding things from different processor architectures could also very well run differently online than offline, but still.
I haven’t looked into act for some time but I remember it NOT being a direct stand in locally. Like it covered 80% of use cases. Maybe that has changed.
I hate GitHub Actions with passion
81–90 of 347 posts
Re: I hate GitHub Actions with passion
#821. Don't use bash, use a scripting language that is more CI friendly. I strongly prefer pwsh. 2. Don't have logic in your workflows. Workflows should be dumb and simple (KISS) and they should call your scripts. 3. Having standalone scripts will allow you to develop/modify and test locally without having to get caught in a loop of hell. 4. Design your entire CI pipeline for easier debugging, put that print state in, e…
I don't agree with (1), but agree with (2). I recommend just putting a Makefile in the repo and have that have CI targets, which you can then easily call from CI via a simple `make ci-test` or similar. And don't make the Makefiles overcomplicated. Of course, if you use something else as a task runner, that works as well.
Re: I hate GitHub Actions with passion
#83Earlier quoted context omitted.
I mean, at some point you are bash calling some other language anyway . I'm a huge fan of "train as you fight", whatever build tools you have locally should be what's used in CI. If your CI can do things that you can't do locally: that is a problem.
> If your CI can do things that you can't do locally: that is a problem. Probably most of the times when this is an actual problem, is building across many platforms. I'm running Linux x86_64 locally, but some of my deliverables are for macOS and Windows and ARM, and while I could cross-compile for all of them on Linux (macOS was a bitch to get working though), it always felt better to compile on the hardware I'm tar…
Re: I hate GitHub Actions with passion
#84Earlier quoted context omitted.
This is basically how most other CI systems work. GitLab CI, Jenkins, Buildbot, Cirrus CI, etc. are all other systems I've used and they work this way. I find GitHub Actions abhorrent in a way that I never found a CI/CD system before...
as usual for Microslop products: it's designed for maximum lock-in everything is including some crappy proprietary yaml rather than using standard tooling so instead of being a collection of easily composable and testable bits it's a mess that only works on their platform
Re: I hate GitHub Actions with passion
#85Earlier quoted context omitted.
> Huh? Who cares if the script is .sh, .bash, Makefile, Justfile, .py, .js or even .php? Me, typically I have found it to be a sign of over-engineering and found no benefits over just using shell script/task runner, as all it should be is plumbing that should be simple enough that a task runner can handle it. > If it works it works, as long as you can run it locally, it'll be good enough, Maybe when it is your own pe…
> But personally so far everytime I have come across something not using a task runner it has just been the wrong decision. Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they impl…
Strong opinions, loosely held :)
> Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering"
Funnily enough running with the first idea I think is creating a lot of the "over-engineering" I am seeing. Not stopping to consider other simpler solutions or even if the problem needs/is worth solving in the first place.
> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end.
I quickly asked Claude to convert one of my open source repos using Make/Nix/Shell -> Python/Nix to see how it would look. It is actually one of the better Python as a task runners I have seen.
* https://github.com/DeveloperC286/clean_git_history/pull/431
While the Python version is not as bad as I have seen previously, I am still struggling to see why you'd want it over Make/Shell.
It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI).
It is less maintainable as it is more code, roughly x3 the amount of the Makefile.
To me the Python code is more verbose and not as simple compared to the Makefile's target so it is less readable as well.
Re: I hate GitHub Actions with passion
#86Re: I hate GitHub Actions with passion
#87The love for Github Actions dissipated fast, it wasn't that long ago we had to read about how amazing Github Actions where. What changed?
(In general, I think a lot of criticisms of GitHub Actions don't consider the fully loaded cost of an alternative -- there are lots of great alternative CI/CD services out there, but very few of them will give you the OS/architecture matrix and resource caps that GitHub Actions gives every single OSS project for free.)
Re: I hate GitHub Actions with passion
#88Re: I hate GitHub Actions with passion
#89Others have pointed out that there are architectural steps you can take to minimize this pain, like keeping all CI operations isolated within scripts that can be run locally (and treating GitHub Actions features purely as progressive enhancements, e.g. only using `GITHUB_STEP_SUMMARY` if actually present).
Another thing that works pretty well to address the feedback loop pain is `workflow_dispatch` + `gh workflow run`: you still need to go through a push cycle, but `gh workflow run` lets you stay in development flow until you actually need to go look at the logs.
(One frustrating limitation with that is that `gh workflow run` doesn't actually spit out the URL of the workflow run it triggers. GitHub claims this is because it's an async dispatch, but I don't see how there can possibly be no context for GitHub to provide here, given that they clearly obtain it later in the web UI.)