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

381–390 of 584 posts

Re: The Pain That Is GitHub Actions

#381

Post by finnthehuman »

badloginagain wrote: post #294
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…

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.

Jenkins is cron with bells and whistles. The result is a pile of plugins to capture all the dimensions of complexity you are likely to otherwise bury in the shell script but want them easier to point and click at. I'll hate on jenkins with the rest of them, but entropy is gonna grow and Jenkins isn't gonna say "no, you can't do that here". I deal with multiple tools where if tried to make fun about how low the jenkins plugin install starts are, you'd know exactly where I work. Once I've calmed down from working on CI I can appreciate Jenkins' attempts to manage all of it.

Any CI product play has to differentiate in a way that makes you dependent on them. Sure it can be superficially nicer when staying inside the guard rails, but in the age of docker why has the number of ways I configure running boring shell scripts gone UP? Because they need me unable to use a lunch break to say "fuck you I don't need the integrations you reserve exclusively for your CI" and port all the jobs back to cron.

And that's why jenkins is king.

Re: The Pain That Is GitHub Actions

#382

Post by neves »

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…

How AWS Code Builder compares? I'm delving into AWS world now.

Re: The Pain That Is GitHub Actions

#383

Post by 999900000999 »

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 not great when you're eating soup

Re: The Pain That Is GitHub Actions

#384

Post by ohgr »

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…

The only people who picked the right tool for the job are the people you don't hear about.

Re: The Pain That Is GitHub Actions

#385

Post by 999900000999 »

ohgr wrote: post #384
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…

The only people who picked the right tool for the job are the people you don't hear about.

That's a good point, at least once a week someone decides that instead of reading the documentation and understanding the limitations of the technologies or frameworks they want to use...

They either just write a long blog post about how they can't screw in nails with a hammer.

Or they leave their security rules wide open and about half the comments are like, we need tools which stop us from doing stupid things.

No other industry works like this.

Re: The Pain That Is GitHub Actions

#386

Post by ptx »

bob1029 wrote: post #374
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…

> Write as much CI logic as possible in your own code This has been my entire strategy since I've been able to do this: https://learn.microsoft.com/en-us/dotnet/core/deploying/#pub... Pulling the latest from git, running "dotnet build" and sending the artifacts to zip/S3 is now much easier than setting up and managing Jenkins, et. al. You also get the benefit of having 100% of your CI/CD pipeline under source control…

> All we needed to do was email the S3 zip link to the customer and they learned a quick procedure to extract it on the server each time.

My concern with this kind of deployment solution, where the customer is instructed to install software from links received in e-mails, is that someone else could very easily send them a link to a malicious installer and they would be hosed. E-mail is not authenticated (usually) and the sender can be forged.

I suppose you could use a shared OneDrive folder or something, which would be safer, as long as the customer doesn't rely on receiving the link to OneDrive by e-mail.

Re: The Pain That Is GitHub Actions

#387

Post by dboreham »

There's a meta-problem here: GitHub Actions is one of those things that when you first encounter it, is presented as: "we've got it all figured out and all goin on here, and anyone who is scratching their head must be dumb". This pattern, in my experience, shows up frequently in the software realm. Then, typically there follows some period where you try to do whatever you need to do by reading docs and copying what you see others do. Frustration and head scratching grows finally culminating in a process of "Ok WTF are the core concepts of this thing, what were they thinking when they designed it, what is it really going???".

The article is what you end up finding after that stage has been gone through.

The conclusion of course is that whoever invented this stuff really wasn't thinking clearly and certainly didn't have the time to write decent documentation to explain what they were thinking. And now the whole world has to try to deal with their mess.

My theory as to how this ends up happening is that the people creating the thing began with some precursor thing as their model. They made the new thing as "old thing, with a few issues fixed". Except they didn't fully understand the concepts in that thing, and we never got to see that thing. You'll see many projects that have this form: bun is "yarn fixed". Yarn is "npm fixed". And so on. None of these projects ever has to fully articulate their concepts.

Re: The Pain That Is GitHub Actions

#388

Post by balls187 »

amtamt wrote: post #277
cnotv wrote: post #224

Earlier quoted context omitted.

Once, a reliable and wise colleague told me "Use in CI what you use locally" and that has been the best devop advice that never failed me to save my time. The second one has been, from someone else: if you can use anything else than bash, do that.

Try brainfuck... Jokes aside... it's so trendy to bash bash that it's not funny anymore. Bash is still quite reliable for work that usually gets done in CI, and nearly maintenance free if used well.

These days, AI Copilots are quite good at helping write and maintain bash (and shell) scripts, that it's not much of a prolem.

Re: The Pain That Is GitHub Actions

#389

Post by mikepurvis »

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…

Strongly isolated systems like Nix and Bazel are amazing for giving no-fuss local reproducibility.

Every CI "platform" is trying to seduce you into breaking things out into steps so that you can see their little visualizations of what's running in parallel or write special logic in groovy or JS to talk to an API and generate notifications or badges or whatever on the build page. All of that is cute, but it's ultimately the tail wagging the dog— the underlying build tool should be what is managing and ordering the build, not the GUI.

What I'd really like for next gen CI is a system that can get deep hooks into local-first tools. Don't make me define a bunch of "steps" for you to run, instead talk to my build tool and just display for me what the build tool is doing. Show me the order of things it built, show me the individual logs of everything it did.

Same thing with test runners. How are we still stuck in a world where the test runner has its own totally opaque parallelism regime and our only insight is whatever it chooses to dump into XML at the end, which will be probably be nothing if the test executable crashes? Why can't the test runner tell the CI system what all the processes are that it forked off and where each one's respective log file and exit status is expected to be?

Re: The Pain That Is GitHub Actions

#390

Post by stared »

solatic wrote: post #370

> Trivial mistakes (formatting, unused deps, lint issues) should be fixed automatically, not cause failures. Do people really consider this best practice? I disagree. I absolutely don't want CI touching my code. I don't want to have to remember to rebase on top of whatever CI may or may not have done to my code. Not all linters are auto-fixable so anyway some of the time I would need to fix it from my laptop. If it's…

I do such things with pre-commit.

Doing it in CI sounds like making things more complicated by resetting to remote branches after pushing commits. And, in the worst case, something that actually brakes code that works locally.

Post reply on HN