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

351–360 of 584 posts

Re: The Pain That Is GitHub Actions

#351

Post by terminalbraid »

enriquto wrote: post #310
terminalbraid wrote: post #215

Earlier quoted context omitted.

> CI files are NOT in the project's repository I don't use sourcehut, but interpreting what you wrote I'd argue this is an antifeature and would be a dealbreaker for me. CI typically evolves with the underlying code and decoupling that from the code makes it difficult to go backwards. It loses cohesion.

you can put them in the same repository, if that is your thing. If you put the build files in a .builds/ folder at the root of your repository, they will be run upon each commit. Just like in github or gitlab. You are just not forced into this way of life. If you prefer, you can store the build files separately, and run them independently of your commits. Moreover, the build files don't need to be associated to any r…

I see, that is nice. Thank you for the patient explanation.

Re: The Pain That Is GitHub Actions

#352

Post by 12_throw_away »

ed_elliott_asc wrote: post #287
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…

* print out the working directory and a directory listing every time

And the environment! (Also, don't put secrets in environment vars)

Re: The Pain That Is GitHub Actions

#353

Post by internetter »

deng wrote: post #190
triyambakam wrote: post #168

Earlier quoted context omitted.

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.

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

A lot of us could learn... do one thing and do it well

Re: The Pain That Is GitHub Actions

#354

Post by amedvednikov »

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…

We recently migrated from YAML CI to VSH as well:

https://github.com/vlang/v/blob/master/ci/linux_ci.vsh

Re: The Pain That Is GitHub Actions

#355

Post by anttiharju »

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.

Enforce on CI. Autofix in pre-commit hooks. Lefthook is fantastic for this.

Example config: https://github.com/anttiharju/vmatch/blob/9e64b0636601c236a5...

Re: The Pain That Is GitHub Actions

#356

Post by 12_throw_away »

jalaziz wrote: post #64
pinkgolem wrote: post #59

Earlier quoted context omitted.

I might have missed the news, but I did not find anything in regards to earthly stopping development What happened there?

I missed it too, but then found this: https://github.com/earthly/earthly/issues/4313

Sigh, this is awful. Earthly is/was not perfect, but is basically the most capable build tool I've ever used. Fingers crossed there's enough enthusiasm in the community to fork it (I'd be organizing it myself if I had any experience with Go at all)

Re: The Pain That Is GitHub Actions

#357

Post by folmar »

jcattle wrote: post #139
out-of-ideas wrote: post #83

Earlier quoted context omitted.

> recently forced to Microsoft Teams my condolences to you and your team for that switch; it's my 2nd used-and-disliked thing (right next to atlassian) - oh well but one cool feature i found with ms teams that zoom did not have (some years ago - no clue now) is turning off incoming video so you dont have to be constantly distracted in meetings edit: oh yeah, re github actions and the user that said: > Glad I’m not th…

I prefer teams just for the fact that by default everyone can mute everyone else in the call. It just gives me peace of mind that if I ever leave my mic on by mistake, someone in the call would have my back and just mute me.

Pretty much any major teleconference software does that for a few years already.

Re: The Pain That Is GitHub Actions

#359

Post by mike_hearn »

DanielHB wrote: post #317
mike_hearn wrote: post #314

Earlier quoted context omitted.

It peaked with Jenkins? I'm curious which CI platforms you've used. I swear by TeamCity. It doesn't seem to have any of these problems other people are facing with GitHub Actions. You can configure it with a GUI, or in XML, or using a type safe Kotlin DSL. These all actually interact so you can 'patch' a config via the GUI even if the system is configured via code, and TeamCity knows how to store config in a git repo…

I think people just hate CI set up by other people. I used TeamCity in a job a few years back and I absolutely hated it, however I imagine a lot of my hatred was the way it was set up. CI is just the thing no one wants to deal with, yet everyone wants to just work. And like any code or process, you need engineering to make it good. And like any project, you can't just blame bad tools for crappy results.

It seems to inspire strong feelings. I set it up at a previous company and at some point after I left they replaced it with Jenkins. However, nobody could explain to me why or what problems they thought they were solving. The feedback was the sort of thing you're saying now: a dislike that can't be articulated.

Whereas, I could articulate why I didn't like Jenkins just fine :)

Re: The Pain That Is GitHub Actions

#360

Post by shykes »

jimmcslim wrote: post #251
oulipo wrote: post #143

Earlier quoted context omitted.

mise ( https://mise.jdx.dev/ ) and dagger ( https://github.com/dagger/dagger ) seem like nice candidates too! Mise can install all your deps, and run tasks

In addition to the other comments suggesting dagger is not the saviour due to being VC-funded, it seems like they have decided there's no money in CI, but AI... yes there's money there! And "something something agents". From dagger.io... "The open platform for agentic software. Build powerful, controllable agents on an open ecosystem. Deploy agentic applications with complete visibility and cross-language capabilitie…

Hello! Dagger CEO here. Yes, we discovered that, in addition to running CI pipelines, Dagger can run AI agents. We learned this because our own users have told us.

So now we are trying to capitalize on it, hence the ongoing changes to our website. We are trying to avoid the "something something agents" effect, but clearly, we still have work to do there :) It's hard to explain in marketing terms why a ephemeral execution engine, cross-language component system, deep observability and interactive CLI can be great at running both types of workloads... But we're going to keep trying!

Internally we never thought of ourselves as a CI company, but as an operating system company operating in the CI market. Now we are expanding opportunistically to a new market: AI agents. We will continue to support both, because our platform can run both.

If you are interested, I shared more details here: https://x.com/solomonstre/status/1895671390176747682

Post reply on HN