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

401–410 of 584 posts

Re: The Pain That Is GitHub Actions

#401

Post by DanHulton »

rbongers wrote: post #391
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…

In my opinion, unless if you need its ability to figure out when something should rebuild or potentially if you already use it, Make is not the right tool for the job. You should capture your pipeline jobs in scripts or similar, but Make just adds another language for developers to learn on top of everything. Make is not a simple script runner. I maintained a Javascript project that used Make and it just turned into…

This is why I've become a huge fan of Just, which is just a command runner, not a build caching system or anything.

It allows you to define a central interface into your project (largely what I find people justify using Make for), but smoothes out so many of the weird little bumps you run into from "using Make wrong."

Plus, you can an any point just drop into running a script in a different language as your command, so it basically "supports bash scripts" too.

https://github.com/casey/just

Re: The Pain That Is GitHub Actions

#402

Post by outofpaper »

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…

Agree with everything except for the avoidance of YAML. What is your rationale for this?

Re: The Pain That Is GitHub Actions

#403

Post by hi_hi »

rrr_oh_man wrote: post #329
hi_hi wrote: post #234

Earlier quoted context omitted.

I came to the exact same conclusion accidentally in my first role as a Tech Lead a few years back. It was a large enterprise CMS project. The client had previously told everyone they couldn't automate deployments due to the hosted platform security, so deployments of code and configs were all done manually by a specific support engineer following a complex multistep run sheet. That was going about as well as you'd ex…

> gorilla consulting Probably 'guerilla', but I like your version more.

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.

Re: The Pain That Is GitHub Actions

#404

Post by esafak »

kelseydh wrote: post #135
xlii wrote: post #103

There is one thing that I haven’t seen mentioned: worst possible feedback loop. I’ve noticed this phenomenon few times already, and I think there’s nothing worse than having a 30-60s feedback loop. The one that keeps you glued to the screen but otherwise is completely nonproductive. I tried for many moons to replicate GHA environment on local and it’s impossible in my context. So every change is like „push, wait for…

Feel this pain so much. If you are debugging Github Action container builds, and each takes over ~40 minutes to build.. you can burn through a whole work day only testing six or seven changes. There has to be a better way. How has nobody figured this out?

There's dagger; CI as code. Test your pipeline locally, in your IDE.

Re: The Pain That Is GitHub Actions

#405

Post by lolinder »

dathinab wrote: post #106
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…

It really depends on what you do? GitHub CI is designed in a way which tends to work well for - languages with no or very very cheap "compilation" steps (i.e. basically only scripting languages) - relatively well contained project (e.g. one JS library, no mono repo stuff) - no complex needs for integration tests - no need for compliance enforcement stuff, especially not if it has to actually be securely enforced inst…

> Also, realistically speaking, a lot of other CI solutions are only marginally better.

This is the key point. Every CI system falls apart when you get too far from the happy path that you lay out above. I don't know if there's an answer besides giving up on CI all together.

Re: The Pain That Is GitHub Actions

#406

Post by actinium226 »

As another commenter said, it's good to write as much CI logic outside the yaml file as possible.

I take this a step further and approach CI with the mentality that I should be able to run all of my CI jobs locally with a decent interface (i.e. not by running 10 steps in a row), and then I use CI to automate my workflow (or scale it, as the case may be). But it always starts with being able to run a given task locally and then building CI on top of it, not building it in CI in the first place.

Re: The Pain That Is GitHub Actions

#407

Post by WhyNotHugo »

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…

If CI just installs some packages and runs `make check` (or something close), then it's going to be much much easier for others to run checks locally.

Re: The Pain That Is GitHub Actions

#408

Post by lolinder »

999900000999 wrote: post #383

Whatever happened to picking the right tool for the job ? It looks like they have a very specific and unique build process which they really should handle with something more customizable like Jenkins. Instead they're using something that's really intended for quick and light deployments for intense dev ops setup. I really like GitHub actions, but I'm only doing very simple things. Don't call a fork bad because it's…

> something more customizable like Jenkins

If they had, we'd be reading a different article about how terribly complex and unintuitive Jenkins is.

CI is just a very very hard problem and no provider makes it easy.

Re: The Pain That Is GitHub Actions

#409

Post by dmuso »

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…

Try doing a clean git clone in TeamCity. Nope, not even with the plugins that claim “clean clone” capability. You should be confident that CI can build/run/test an app with a clean starting point. If the CI forces a cached state on an agent that you can’t clear… TeamCity just does it wrong.

Re: The Pain That Is GitHub Actions

#410

Post by K3UL »

As someone who's been using it at very large scale, I still miss gitlab but I think they are not that bad.

But two major pains I did not see : the atrocious UI and the pricing.

Their pricing model goes against any good practice, as it counts a minute for any job even if it runs for 2 seconds. Let's say you run 100jobs in parallel and they all take 30sec. You will pay 100 minutes instead of 50. Now translate this to an enterprise operating at a big scale and I assure you have seen crazy differences between actual time and billable time.

Post reply on HN