Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Actions is slowly killing engineering teams

iankduncan.com

Post reply on HN
Print view View original

161–170 of 219 posts

Re: GitHub Actions is slowly killing engineering teams

#161

Post by slackfan »

tedk-42 wrote: post #135
slackfan wrote: post #5

All CI is just various levels of bullshit over a bash script anyway.

Yes, but no need for the attitude. Linux powers the world in this area and bash is the glue which executes all these commands on servers. Any program or language you write to try and 'revolutionise CI' and be this glue will ultimately make the child process call to a bash/sh terminal anyhow and you need to read both stdout and stderr and exit codes to figure out next steps. Or you can just use bash.

>no need for the attitude

Why? We've spent years upon years upon years of building systems that enshittify processes. We've spent years losing talent in the industry and the trends aren't going to reverse. We are our own worst enemy, and are directly responsible for the state of the industry, and to an extent, the world.

To not call out bullshit where one sees it, is violence.

Re: GitHub Actions is slowly killing engineering teams

#162

Post by maccard »

mickeyp wrote: post #88
wtcactus wrote: post #83

Earlier quoted context omitted.

I agree, but this is kind of an unachievable dream in medium to big projects. I had this fight for some years in my present work and was really nagging in the beginning about the path we were getting into by not allowing the developers to run the full (or most) of the pipeline in their local machines… the project decided otherwise and now we spend a lot of time and resources with a behemoth of a CI infrastructure bec…

It's not an unachievable dream. It's a trade-off made by people who may or may not have made the right call. Some things just don't run on a local machine: fair. But a lot of things do, even very large things. Things can be scaled down; the same harnesses used for the development environment and your CI environment and your prod environment. You don't need a full prod db, you need a facsimile mirroring the real thing…

> You don't need a full prod db, you need a facsimile mirroring the real thing but 1/50th the size.

My experience has been that the problems in CI systems come from exactly these differences “works on my machine” followed by “oops, I guess the build machine doesn’t have access to that random DB”, or “docker push fails in our CI environment because credentials/permissions, but it works when I run it just on my machine”

Re: GitHub Actions is slowly killing engineering teams

#163

Post by plqbfbv »

I mostly agree with the points, but I've also managed to throw AI efficiently at the problem.

We're running a self-hosted GitLab -> hosted GitHub migration at my company (which to me feels a downgrade), and without LLMs I would have spent weeks just researching syntax for how to implement the requirements I had.

I asked Claude to simply "translate these GL templates to GH actions, I want 1 flow for this, 1 flow for that, etc" and it mostly worked. Then in the repos I link the template and ask Claude to write the workflow that uses the template with the correct inputs. I think I saved maybe 3 months worth of coding and debugging workflows. Besides maybe picking slightly outdated actions (e.g. action@v4 instead of action@v6), 95% of the work was ok, and I had to tweak a couple things afterwards.

Re: GitHub Actions is slowly killing engineering teams

#164

Post by Storment33 »

iberator wrote: post #71
habosa wrote: post #25

Dead on. GitHub Actions is the worst CI tool I’ve ever used (maybe tied with Jenkins) and Buildkite is the best. Buildkite’s dynamic pipelines (the last item in the post) are so amazingly useful you’ll wonder how you ever did without them. You can do super cool things like have your unit test step spawn a test de-flaking step only if a test fails. Or control test parallelism based on the code changes you’re testing.…

what's wrong with Jenkins? It's battle tested and hardened. Works flawless even with thousands of tasks, and WORKS OUT OF THE BOX. imo top 10 best admin/devs free software written in past 25 years.

I mean all CIs work out of the box, although I have no interest in self hosting CI.

Jenkins is probably a bit like Java, technically it is fine. The problem is really where/who typically uses it and as there is so much freedom it is really easy to make a monster. Where as for Go it is a lot harder to write terrible unmaintainable code compared to Java.

Re: GitHub Actions is slowly killing engineering teams

#165

Post by timw4mail »

arielcostas wrote: post #157
nicoburns wrote: post #138

Earlier quoted context omitted.

https://github.com/casey/just is an uncursed make (for task running purposes - it's not a general build system)

How does `just` compare to Task ( https://taskfile.dev/ )?

Just uses make-like syntax, not yaml, which I view as a huge advantage.

Re: GitHub Actions is slowly killing engineering teams

#166

Post by Storment33 »

computerfriend wrote: post #33
harikb wrote: post #23

Ian Duncan, I was imagining you on a stage delivering this as a standup comedy show on Netflix. My pet peeve with Github Actions was that if I want to do simple things like make a "release", I have to Google for and install packages from internet randos. Yes, it is possible this rando1234 is a founding github employee and it is all safe. But why does something so basic need external JS? packages?

Yeah, their "standard library" so to speak (basically everything under the actions org) is lacking. But for this specifically, you can use the gh CLI.

This is what I done, GitHub Actions is basically a command line as a service for my projects. It does nothing but checkout the code, means I can do all the releasing, artefact uploading, compiling & testing etc locally.

Re: GitHub Actions is slowly killing engineering teams

#169

Post by ccvannorman »

I just finished an implementation of CI across three codebases totalling >50k lines and I can confirm a lot of the author's pain points, especially around logging and YAML variables.

Commit with one character YAML difference? Check.

Commit with 2-3 YAML lines just to add the right logging? Check.

Wait 5+ minutes for a YAML diff to propagate through our test pipeline for the nth time today? .. sigh .. check

BUT, after ironing all these things out (and running our own beefy self-hosted runner which is triggered to wake up when there's a test process to snack on), it's .. uh.. not so bad? For now?

Re: GitHub Actions is slowly killing engineering teams

#170

Post by mickeyp »

krautsauer wrote: post #137
mickeyp wrote: post #75

The winning strategy for all CI environments is a build system facsimile that works on your machine, your CI's machine, and your test/uat/production with as few changes between them as your project requirements demand. I start with a Makefile. The Makefile drives everything. Docker (compose), CI build steps, linting, and more. Sometimes a project outgrows it; other times it does not. But it starts with one unitary to…

Make is incredibly cursed. My favorite example is it having a built-in rule (oversimplified, some extra Makefile code that is pretended to exist in every Makefile) that will extract files from a version control system. https://www.gnu.org/software/make/manual/html_node/Catalogue... What you're saying is essentially ”Just Write Bash Scripts”, but with an extra layer of insanity on top. I hate it when I encounter a pro…

No I'm saying use Makefiles, which work just fine. Mark your targets with PHONY and move on.
Post reply on HN