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

341–350 of 584 posts

Re: The Pain That Is GitHub Actions

#341

Post by bluGill »

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.

I would feel that way but I've had the misfortune to work with a wide open ci system where any developer could make thanges and one guy did. The locked down system prevents me form some changes I want but in return my builds don't suddenly start failing because some ci option was turned on for everyone.

Re: The Pain That Is GitHub Actions

#342

Post by pdimitar »

verdverm wrote: post #309
zamalek wrote: post #281

Earlier quoted context omitted.

> I'm not convinced it's any better. Your Jenkins experience is more valuable and worth replicating when you get the opportunity.

We're doing the same, but replacing the bash script with Dagger. Once you get on Dagger, you can turn your CI into minimal Dagger invocations and write the logic in the language of your choice. Runs the same locally and in automation

Would love to see a more detailed write-up on this way of using Dagger.

Re: The Pain That Is GitHub Actions

#343

Post by __float »

mike_hearn wrote: post #314
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.

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…

TeamCity's "config as code" feels a bit like an afterthought to me. (It's very Windows-style, where PowerShell got bolted on, and you're still fighting a bit of an upstream current getting clickops users out of old habits. I've also only experienced it at .NET-stack jobs, though, so I might be a bit biased :-)

(I don't recall _loving_ it, though I don't have as many bad memories of it as I do for VSTS/TFS, GitLab, GH Actions, Jenkins Groovyfiles, ...)

Re: The Pain That Is GitHub Actions

#344

Post by verdverm »

pdimitar wrote: post #342
verdverm wrote: post #309

Earlier quoted context omitted.

We're doing the same, but replacing the bash script with Dagger. Once you get on Dagger, you can turn your CI into minimal Dagger invocations and write the logic in the language of your choice. Runs the same locally and in automation

Would love to see a more detailed write-up on this way of using Dagger.

The idea is a common pattern among Dagger users, but you can do the same with bash scripts, python, or any entrypoint. It's more of a CI ethos, and for me Dagger is an implementation detail.

I personally hold Dagger a bit different from most, by writing a custom CLI and using the Dagger Go SDK directly. This allows you to do more host level commands, as everything in a Dagger session runs in a container (builds and arbitrary commands).

I've adopted the mono/megarepo organization and have a pattern that also includes CUE in the solution. Starting to write that up here: https://verdverm.com/topics/dev/dx

Re: The Pain That Is GitHub Actions

#345

Post by orliesaurus »

I am building Toolhouse.ai and I've had headaches with Github actions but luckily I ask the AI to help out when I am trying to do something. My biggest annoyance is that it's oddly hard to debug things without running it. Even the Github Actions syntax helper on VSCode isn't super helpful. I have recently discovered `act`[1] and I will be investing time to using it because it really * hopefully * makes a difference.

[1]https://github.com/nektos/act

Re: The Pain That Is GitHub Actions

#346

Post by djha-skin »

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 couldn't agree more, really. My whole career points to this as the absolute correct advice in CI.

Re: The Pain That Is GitHub Actions

#347

Post by __float »

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…

I can't really fault them too much for hopping on the latest bandwagon, if their software is general enough at running workflows for it to fit.

They do seem to have a nice "quickstart for CI" they haven't abandoned, yet: https://docs.dagger.io/ci/quickstart

(As much as I personally like working with CI and build systems, it's true there's not a ton of money in it!)

Re: The Pain That Is GitHub Actions

#348

Post by trevor-e »

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…

I thought the same until having to do slightly more complicated and "off the beaten path" workflows. I'm still amazed at how easy they make building CI jobs now, but I also get frustrated at how it's not a "local first" workflow that you then push to their service.

Re: The Pain That Is GitHub Actions

#349

Post by no_wizard »

baq wrote: post #118
ehansdais wrote: post #111

Earlier quoted context omitted.

After years of trial and error our team has come to the same conclusion. I know some people might consider this insanity, but we actually run all of our scripts as a separate C# CLI application (The main application is a C# web server). Effectively no bash scripts, except as the entry point here and there. The build step and passing the executable around is a small price to pay for the gain in static type checking, b…

> I know some people might consider this insanity Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. This is insane. You’re actually introducing much needed sanity into the process by admitting that a real programming language is the tool to use here. I can’t imagine the cognitive dissonance Lisp folks have when dealing with this madness, not be…

I'm shocked there isn't a 'language for config' that hasn't become the de facto standard and its YAML all the way down seemingly. I am with you 100%.

It would really benefit from a language that intrinsically understood its being used to control a state machine. As it is, that is what nearly all folks want in practice is a way to run different things based on different states of CI.

A lisp DSL would be perfect for this. Macros would make things alot easier in many respects.

Unfortunately, there's no industry consensus and none of the big CI platforms have adopted support for anything like that, they all use variants of YAML (I always wondered who started it with YAML and why everyone copied that, if anyone knows I'd love to read about it).

Honestly, I can say the same complaints hold up against the cloud providers too. Those 'infrastructure as code' SDKs really don't lean into the 'as code' part very well

Re: The Pain That Is GitHub Actions

#350

Post by 12_throw_away »

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.

> Why does YAML have any traction when JSON is right there?

Because it has comments, which are utterly essential for anything used as a human readable/writable configuration file format (your use case, with 1 MB of data, needs a data interchange format, for which yes JSON is at least much better than YAML).

Post reply on HN