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

The Pain That Is GitHub Actions

feldera.com

Post reply on HN
Print view View original

331–340 of 584 posts

Re: The Pain That Is GitHub Actions

#331

Post by anttiharju »

quesera wrote: post #313
joshstrange wrote: post #254

Earlier quoted context omitted.

Things like this are why I hate having to use PATs in workflows. What if I leave the company? I’ll leave a wake of broken actions in my wake. I do not like that at all, a huge point of CI/CD is automation, reproducibility, and NOT being dependent on specific developers/machines.

I believe this is a good use for a GitHub machine account. IIRC, GitHub recommends this practice in their docs, with a username of "YOUR_USERNAME-machine". The machine user is just an ordinary GitHub user, added as a member of the organization, with all the necessary repo permissions, and a generated access token added to the GH repo Secrets. The organization owner then manages this GH machine account as well as the…

Using machine/service accounts across an org can (relatively) easily hit rate limits, better way is to use a github app instead for generating the tokens: https://github.com/peter-evans/create-pull-request/blob/main...

Re: The Pain That Is GitHub Actions

#332

Post by thom »

tobinfekkes wrote: post #81

This is the joy of HN, for me, at least. I'm genuinely fascinated to read that both GitHub Actions and DevOps are (apparently) so universally hated. I've been using both for many years, with barely a hiccup, and I actually really enjoy and value what they do. It would never have dawned on me, outside this thread, to think that so many people dislike it. Nice to see a different perspective! Are the Actions a little cu…

Unless I'm misunderstanding, you can use workflow_dispatch to avoid having to make useless commits to trigger actions.

Re: The Pain That Is GitHub Actions

#333

Post by shykes »

Aeolun wrote: post #87
deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

This is where I was going to say something about dagger, but it seems it turned into AI crud. Let me at least recommend depot.dev for having absurdly fast runners.

Hello! Dagger CEO here. We are indeed getting an influx of AI workloads (AI agents to be specific, which is the fancy industry term for "software with LLMs inside"), and are of course trying to capitalize on that in our marketing material. We're still looking for the right balance of CI and AI on our website. Crucially, it's the same engine running both. Because, as it turns out, AI agents are mostly workflows under the hood, and Dagger is great at running those.

I shared more context in this thread: https://x.com/solomonstre/status/1895671390176747682

Re: The Pain That Is GitHub Actions

#335

Post by DonHopkins »

rrr_oh_man wrote: post #329
hi_hi wrote: post #234

Earlier quoted context omitted.

I came to the exact same conclusion accidentally in my first role as a Tech Lead a few years back. It was a large enterprise CMS project. The client had previously told everyone they couldn't automate deployments due to the hosted platform security, so deployments of code and configs were all done manually by a specific support engineer following a complex multistep run sheet. That was going about as well as you'd ex…

> gorilla consulting Probably 'guerilla', but I like your version more.

That's when the devs all wear gorilla suits in Zoo meetings.

Wikipedia: Gorilla Suit: National Gorilla Suit Day:

https://en.wikipedia.org/wiki/Gorilla_suit#National_Gorilla_...

Put the Gorilla back in National Gorilla Suit Day:

https://www.instagram.com/mad.magazine/p/C2xgmVqOjL_/

Gorilla Suit Day – January 31, 2026:

https://nationaltoday.com/gorilla-suit-day/

National Gorilla Suit Day:

https://www.youtube.com/watch?v=N2n5gAN3IlI

Re: The Pain That Is GitHub Actions

#336

Post by mscrivo »

rsanheim wrote: post #325
ashishb wrote: post #48

Earlier quoted context omitted.

> There are better solutions out there. And what are those?

CircleCI.

To expand on this, CircleCI lets you easily ssh into a run so you can debug it as if you were debugging it on your own machine. I cannot tell you how many times this has saved me countless hours because you don't need to wait for your changes to build and then subsequently fail repeatedly, drastically shortening the iteration cycle.

Re: The Pain That Is GitHub Actions

#337

Post by ZeWaka »

akanapuli wrote: post #319
JanMa wrote: post #112

Earlier quoted context omitted.

Whenever possible I now just use GitHub actions as a thin wrapper around a Makefile and this has improved my experience with it a lot. The Makefile takes care of installing all necessary dependencies and runs the relevant build/Test commands. This also enables me to test that stuff locally again without the long feedback loop mentioned in other comments in this thread.

I dont quite understand the benefit. How does running commands from the Makefile differ from running commands directly on the runner ? What benefit does Makefile brings here ?

You can't run GitHub actions yml workflows locally (officially, there's tools like act).

Re: The Pain That Is GitHub Actions

#338

Post by skor »

badloginagain wrote: post #294
hi_hi wrote: post #234

Earlier quoted context omitted.

I came to the exact same conclusion accidentally in my first role as a Tech Lead a few years back. It was a large enterprise CMS project. The client had previously told everyone they couldn't automate deployments due to the hosted platform security, so deployments of code and configs were all done manually by a specific support engineer following a complex multistep run sheet. That was going about as well as you'd ex…

I hate the fact that CI peaked with Jenkins. I hate Jenkins, I hate Groovy, but for every company I've worked for there's been a 6-year-uptime Jenkins instance casually holding up the entire company. There's probably a lesson in there.

well, I got tired of Groovy and found out that using Jenkins with plain bash under source control is just right for us. Runs everywhere, very fast to test/develop and its all easy to change and improve.

We build Docker images mostly so ymmv.

I have a "port to github actions" ticket in the backlog but I think we're not going to go down that road now.

Re: The Pain That Is GitHub Actions

#339

Post by sofixa »

philistine wrote: post #324
deng wrote: post #86

Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…

> * Avoid YAML as much as possible, period. Why does YAML have any traction when JSON is right there? I'm an idiot amateur and even I learned this lesson; my 1 MB YAML file full of data took 15 seconds to parse each time. I quickly learned to use JSON instead, takes half a second.

Because YAML, as much as it sucks, is relatively straightforward to write by humans. It sucks to read and parse, you can make tons of small mistakes that screw it up entirely, but it's still less cruft than tons of needless "": { } .

For short configs, YAML is acceptable-ish. For anything longer I'd take TOML or something else.

Re: The Pain That Is GitHub Actions

#340

Post by __float »

skor wrote: post #338
badloginagain wrote: post #294

Earlier quoted context omitted.

I hate the fact that CI peaked with Jenkins. I hate Jenkins, I hate Groovy, but for every company I've worked for there's been a 6-year-uptime Jenkins instance casually holding up the entire company. There's probably a lesson in there.

well, I got tired of Groovy and found out that using Jenkins with plain bash under source control is just right for us. Runs everywhere, very fast to test/develop and its all easy to change and improve. We build Docker images mostly so ymmv. I have a "port to github actions" ticket in the backlog but I think we're not going to go down that road now.

Yeah, I've come back around to this: you do not want "end users" writing Groovy, because the tooling around it is horrible.

You'll have to explain the weird CPS transformations, you'll probably end up reading the Jenkins plugins' code, and there's nothing fun down this path.

Post reply on HN