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

171–180 of 584 posts

Re: The Pain That Is GitHub Actions

#171

Post by KronisLV »

throwaway984393 wrote: post #56
ashishb wrote: post #48

Earlier quoted context omitted.

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

Drone.io

Not sure why this was downvoted/flagged, I do use Drone CI myself currently and it's quite pleasant: https://www.drone.io/

There's also the Woodpecker CI fork, which has a very similar user experience: https://woodpecker-ci.org/

When combined with Docker images, it's quite pleasant to use - you define what environment you want for the CI/CD steps, what configuration/secrets you need and define the steps (which can also just be a collection of scripts that you can run locally if need be), that's it.

Standalone, so you can integrate it with Gogs, Gitea or similar solutions for source control and perhaps a bit simpler than GitLab CI (which I also think is lovely, though maintaining on-prem GitLab isn't quite a nice experience all the time, not that you have to do that).

Re: The Pain That Is GitHub Actions

#172

Post by SkiFire13 »

kylegalbraith wrote: post #55

This was an interesting read and highlighted some of the author's top-of-mind pain points and rough edges. However, in my experience, this is definitely not an exhaustive list, and there are actually many, many, many more. Things like 10 GB cache limits in GitHub, concurrency limits based on runner type, the expensive price tag for larger GitHub runners, and that's before you even get to the security ones. Having bee…

By what measure is this "exponentially faster"? Surely GH doesn't take an exponential time in the number of steps of the workflow...

Re: The Pain That Is GitHub Actions

#173

Post by hinkley »

yeswecatan wrote: post #78
hinkley wrote: post #72

Earlier quoted context omitted.

There's a long set of steps to making a tool mandatory in a development environment, but the final step should always, always be, "And you will find yourself on a PIP if you refuse to use the mandatory tools." If people want to die on a hill that is demonstrably causing problems for all of their coworkers then let em.

Oh how I wish engineering leadership would actually mandate certain things such as this.

They always pick the wrong things to mandate don't they.

Re: The Pain That Is GitHub Actions

#174

Post by mschuster91 »

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…

> Some people here still can’t believe YAML is used for not only configuration, but complex code like optimized CI pipelines. This is insane.

It's miles better than Jenkins and the horrors people created there. GitLab CI can at least be easily migrated to any other GitLab instance and stuff should Just Work because it is in the end not much more than self contained bash scripts, but Jenkins... is a clown show, especially for Ops people of larger instances. On one side, you got 50 plugins with CVEs but you can't update them because you need to find a slot that works for all development teams to have a week or two to fix their pipelines again, and on the other side you got a Jenkins instance for each project which lessens the coordination effort but you gotta worry about dozens of Jenkins instances. Oh and that doesn't include the fact many old pipelines aren't written in Groovy or, in fact, in any code at all but only in Jenkins's UI...

Github Actions however, I'd say for someone coming from GitLab, is even worse to work with than Jenkins.

Re: The Pain That Is GitHub Actions

#175

Post by stinos »

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 because if you want a release you just build it locally.

The only thing it won't automaticaly do out of the box is being fast, because obviously this script also needs to setup most of the build environment. So depending on the exact implementation there's variation in the split between what constitutes setting up a build environment and running the CI script. As in: for some tools our CI scripts will do 'everything' so starting from a minimal OS install. Whereas others expect an OS with build tools and possibly some dependencies already available.

Re: The Pain That Is GitHub Actions

#176

Post by Aeolun »

kylegalbraith wrote: post #55

This was an interesting read and highlighted some of the author's top-of-mind pain points and rough edges. However, in my experience, this is definitely not an exhaustive list, and there are actually many, many, many more. Things like 10 GB cache limits in GitHub, concurrency limits based on runner type, the expensive price tag for larger GitHub runners, and that's before you even get to the security ones. Having bee…

Depot is fantastic. Can heavily recommend it. It’s like magic when your builds suddenly take 1m instead of 5+ just by switching the runner.

Re: The Pain That Is GitHub Actions

#177

Post by ManBeardPc »

CI environments like Gitlab or Github are my nemesis. Another technology that everyone swears is absolute necessary but somehow makes everything more complicated. The provided environments in companies so far are hell 100% the time and managed by inexperienced personnel with zero or little programming experience.

* Barely reproducible because things like the settings of the server (environment variables are just one example) are not version controlled.

* Security is a joke.

* Programming in YAML or any other config format is almost always a mistake.

* Separate jobs often run in their own container, losing state like build caches and downloaded dependencies. Need to be brought back by adding remote caches again.

* Massive waste of resources because too many jobs install dependencies again and again or run even if not necessary. Getting the running conditions for each step right is a pain.

* The above points make everything slow as hell. Spawning jobs takes forever sometimes.

* Bonus points if everything is locked down and requires creating tickets.

* Costs for infra often keep expanding towards infinity.

We already have perfectly fine runners: the machines of the devs. Make your project testable and buildable by everyone locally. Keep it simple and avoid (brittle) dependencies. A build.sh/test.sh/release.sh (or in another programming language once it gets more complicated, see Bun.build, build.zig) and a simple docker-compose.yml that runs your DB, Pub-Sub or whatever. Works pretty well in languages like Go, Rust or TS (Bun). Having results in seconds even if you are offline or the company network/servers have issues is a blessing for development.

There are still things like the mentioned heavy integration tests, merges to main and the release cycle where it makes sense to run it in such environments. I'm just not happy how this CI/CD environments work and are used currently.

Re: The Pain That Is GitHub Actions

#178

Post by ironmagma »

dkdbejwi383 wrote: post #154
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!

The pain points sound pretty trivial though. You notice a deprecation warning in the logs, or an email from GitHub and you make a 1 line commit to bump the node version. Easy. Sure you can make typos that you don’t spot until you’ve pushed and the action doesn’t run, but I quickly learned to stop being lazy and actually think about what I’m writing, and get someone else to do an actual review (not just scroll down an…

The non-solution solution, to simply downplay the issues instead of fixing them. You can solve almost anything this way, but also isn't it nice when things around you aren't universally slightly broken?

Re: The Pain That Is GitHub Actions

#179

Post by [deleted] »

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.

[deleted]

Re: The Pain That Is GitHub Actions

#180

Post by madeofpalk »

imp0cat wrote: post #147
saidinesh5 wrote: post #96

Earlier quoted context omitted.

Caching is nicer on own runners. No need to redownload 10+GB of "development container images" just to build your 10 lines of changed code. With self hosted Gitlab runners it was almost as fast as doing incremental builds. When your build process can take like 15-20 minutes (medium sized C++ code base), this brought down the total time to 30 seconds or so.

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?
Post reply on HN