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

181–190 of 584 posts

Re: The Pain That Is GitHub Actions

#181

Post by crabbone »

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…

First of all, I cannot agree more, given what we have today.

Unfortunately, this isn't a good plan going forward... :( Going forward I'd wish for a tool that's as ubiquitous as Git, has good integration with editors like language servers, can be sold as a service or run completely in-house. And it would allow defining the actions of the automated builds and tests, have a way of dealing with releases, expose interface for collecting statistics, integrate with bug tracing software for the purpose of excluding / including tests in test runs, allowed organizing tests in groups (eg. sanity / nightly / rc).

The problem is that tools today don't come anywhere close to being what I want for CI, neither free nor commercial tools aren't even going in the desired direction. So, the best option is simply to minimize their use.

Re: The Pain That Is GitHub Actions

#182

Post by xyzal »

stinos wrote: post #175
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. I don't know which guru came up with it but this is the 'one-click build' principle. If youcan't do that, you have a problem. So if even remotely possible we write all CI as a single 'one-click' script which can do it all by itself. Makes developing/testing the whole CI easy. Makes changing between CI implementations easy. Can solve really nasty issues (think: CI is down, need to send update to customer) easily…

I think it was mentioned as a part of the 'Joel test'

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

Re: The Pain That Is GitHub Actions

#183

Post by rgilton »

oulipo wrote: post #142

I wanted to try dagger to solve some of these issues ( https://github.com/dagger/dagger ) anyone has feedback on it?

Yep, after spending a few years with gitlab pipelines, my company started migrating over to dagger roughly mid-2024.

We moved to dagger to get replicable local pipeline runs, escape the gitlab DSL, and get the enormous benefits of caching.

We have explicitly chosen to avoid using the "daggerverse", and with that the cross-language stuff. Reason being that it makes modifying our pipeline slower and harder -- the opposite of the reason we moved to dagger.

So we use the Dagger python API to define and run our CI builds. It's great!

Like the other comments on this page about dagger, the move to "integrate AI" is highly concerning. I am hopeful that they won't continue down this path, but clearly the AI hype bubble is strong and at least some of the dagger team are inside it.

I'm speculating that if the dagger team doesn't drop the AI stuff, then the dagger project will end. A fork will pop-up and we'll move to using that. Not an expert (yet!) in the buildkit API, but it seems like the stuff we're benefiting from with dagger is really just a thin wrapper around buildkit. So potentially not too challenging to create a drop-in replacement if necessary later.

Re: The Pain That Is GitHub Actions

#184

Post by tasuki »

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…

Yes, your needs are simple. I've also been using GitHub actions for all my needs since Travis shut down and haven't run into any problems.

I wouldn't want to maintain GitHub actions for a large project involving 50 people and 5 languages...

Re: The Pain That Is GitHub Actions

#185

Post by speleding »

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 would like to add one point:

* Consider whether it's not easier to do away with CI in the cloud and just build locally on the dev's laptop

With fast laptops and Docker you can get perfectly reproducible builds and tests locally that are infinitely easier to debug. It works for us.

Re: The Pain That Is GitHub Actions

#186

Post by saidinesh5 »

madeofpalk wrote: post #180
imp0cat wrote: post #147

Earlier quoted context omitted.

This. Your own runners can cache everything (docker caches, apt caches, ccache outputs...) and can also share the compilation load (icecc for c++). All that gives 5x-10x speed boost.

This is true because your CI steps will be running on a lower number of physical machines, ensuring higher cache hits?

Kind of - you can also pin runners.("This workflow runs on this runner always"). And caching just means not deleting the artifacts from the file system from the previous runs.

Imagine building Android - even "cloning the sources" is 200GB of data transfer, build times are in hours. Not having to delete the previous sources and doing an incremental build saves a lot of everything.

Re: The Pain That Is GitHub Actions

#187

Post by doix »

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 came from the semiconductor industry, where everything was locally hosted Jenkins + bash scripts. The Jenkins job would just launch the bash script that was stored in perforce(vcs), so all you had to do to run things locally was run the same bash script.

When I joined my first web SaaS startup I had a bit of a culture shock. Everything was running on 3rd party services with their own proprietary config/language/etc. The base knowledge of POSIX/Linux/whatever was almost completely useless.

I'm kinda used to it now, but I'm not convinced it's any better. There are so many layers of abstraction now that I'm not sure anybody truly understands it all.

Re: The Pain That Is GitHub Actions

#188

Post by crabbone »

alex_suzuki wrote: post #88
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…

> * Always use your own runners, on-premise if possible Why? I understand it in cases where security is critical or intellectual property is at stake. Are you talking about "snowflake runners" or just dumb executors of container images?

Debugging and monitoring. When the runner is somewhere else, and is shared nobody is going to give you full access to the machine.

So many times I was biting my fingers not being able to figure out the problems GitHub runners were having with my actions and was unable to investigate.

Re: The Pain That Is GitHub Actions

#189

Post by Aeolun »

oulipo wrote: post #144
Aeolun wrote: post #87

Earlier quoted context omitted.

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.

can you give more feedback about dagger? what is good/not good about it? I was going to start looking into it

I liked their setup before, though I never got around to actually using it, but the tagline on the website has changed to “AI powered workflow orchestration”, which is quite different from the original “Write pipeline once, run everywhere”

Re: The Pain That Is GitHub Actions

#190

Post by deng »

triyambakam wrote: post #168
lou1306 wrote: post #157

Earlier quoted context omitted.

> * Don't bind yourself to some fancy new VC-financed thing that will solve CI once and for all but needs to get monetized eventually (see: earthly, dagger, etc.) Literally from comment at the root of this thread.

But are mise and dagger VC funded? I don't see any pricing pages there.

Dagger is even YCombinator funded.

https://www.boringbusinessnerd.com/startups/dagger

Mise indeed isn't, but its scope is quite a bit smaller than Dagger.

Post reply on HN