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

431–440 of 584 posts

Re: The Pain That Is GitHub Actions

#431

Post by Marsymars »

raffraffraff wrote: post #100
IshKebab wrote: post #91

Earlier quoted context omitted.

Sounds like you have the same pain points as everyone else; you're just more willing to ignore them. I am with the author - we can do better than the status quo!

It probably depends on your org size and how specialised you are. Right now I dislike GitHub Actions and think that Gitlab CI is way better, but I also don't give it to much thought because it's a once in a blue moon task for me to mess with them. But I would absolutely hate to be a "100% DevOps guy" for a huge organisation that wants me to specialise in this stuff all the time. I think that by the end of week 1 I'd…

I don't mind it per se; to me the problem is then that some devs don't bother with basic debugging steps of CI failures - if anything works locally and fails in CI, their first step is to message me - so instead of being "100% DevOps" I spend a pile of time debugging other devs' local environments.

Re: The Pain That Is GitHub Actions

#432

Post by QuercusMax »

maest wrote: post #413
hi_hi wrote: post #403

Earlier quoted context omitted.

Haha, I'm gonna admit it, all these years and I thought gorilla/guerilla was one of those American/British spelling things, like cheque/check or gaol/jail. Boy do I feel stupid.

..."gaol"?

It's the British spelling of "jail", as in "John Bunyan, a prominent Puritan preacher and author, spent 12 years in Bedford Gaol from 1660 to 1672." Pronounced jail, I believe.

Re: The Pain That Is GitHub Actions

#433

Post by michpoch »

Marsymars wrote: post #429
stared wrote: post #390

Earlier quoted context omitted.

I do such things with pre-commit. Doing it in CI sounds like making things more complicated by resetting to remote branches after pushing commits. And, in the worst case, something that actually brakes code that works locally.

I have team members who complain that installing and running pre-commit is too much overhead, so instead I see them pushing commit after broken commit that tie up CI resources to fail on the pre-commit workflow. :(

> I have team members who complain that installing and running pre-commit is too much overhead

Why do they have a say in this? This is up to tech leadership to set standards that need to be followed.

Re: The Pain That Is GitHub Actions

#434

Post by michpoch »

yeswecatan wrote: post #32
lemagedurage wrote: post #26

I wonder if the complexity of fixing trivial code mistakes in CI is worth it compared to catching them in a pre-commit hook.

Unfortunately people will use --no-verify to bypass hooks.

Then they'll lose time for the same verifications to fail in the PR?

Re: The Pain That Is GitHub Actions

#435

Post by jiehong »

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…

I always thought it could be cool to use systemd as a CI agent replacement someday:

Each systemd service could represent a step built by running a script, and each service can say what it depends on, thus helping parallelize any step that can be.

I have not found anyone trying that so far. Is anybody aware of something similar and more POSIX/cross platform that allows writing a DAG of scripts to execute?

Re: The Pain That Is GitHub Actions

#436

Post by iloveitaly »

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…

I very much agree here. I've had the best luck when there is as little as possible config in CI as possible:

- mise for lang config

- direnv for environment loading

- op for secret injection

- justfile for lint, build, etc

Here's a template repo that I've been working on that has all of this implemented:

https://github.com/iloveitaly/python-starter-template

It's more complex than I would like it to be, but it's consistent and avoids having to deal with GHA too much.

I've also found having a GHA playground is helpful:

https://github.com/iloveitaly/github-action-playground

Re: The Pain That Is GitHub Actions

#437

Post by jalaziz »

lsuresh wrote: post #414
pimeys wrote: post #268

Earlier quoted context omitted.

We switched to Depot last week. Our Rust builds went down from 20+ minutes to 4-8 minutes. The easy setup and their docker builds with fast caching are really good.

This sounds promising. What made your Rust builds become that fast? Any repo you could point us to?

Check out this Dockerfile template if you're building Rust in Docker: https://depot.dev/docs/container-builds/how-to-guides/optima...

What makes Depot so fast is that they use NVMe drives for local caching and they guarantee that the cache will always be available for the same builders. So you don't suffer from the cold-start problem or having to load your cache from slow object storage.

Re: The Pain That Is GitHub Actions

#439

Post by jalaziz »

shykes wrote: post #366
jalaziz wrote: post #53

GitHub Actions started off great as they were quickly iterating, but it very much seems that GitHub has taken its eye of the ball and the improvements have all but halted. It's really upsetting how little attention Actions is getting these days ( https://github.com/orgs/community/discussions/categories/act... > tells the story -- the most popular issues have gone completely unanswered). Sad to see Earthly halting dev…

> Sad to see Earthly halting development and Dagger jumping on the AI train :(. Hopefully we'll get a proper alternative. Hi, Dagger CEO here. We're advertising a new use case for Dagger (running AI agents) while continuing to support the original use case (running complex builds and tests). Dagger has always been a general purpose engine, and our community has always used it for more than just CI. It's still the exa…

Great to know. I think the fear is that so many companies are prioritizing AI workloads for the valuation bump rather than delivering actual meaningful value.
Post reply on HN