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

441–450 of 584 posts

Re: The Pain That Is GitHub Actions

#441

Post by suryao »

lsuresh wrote: post #414
pimeys wrote: post #268

Earlier quoted context omitted.

We switched to Depot last week. Our Rust builds went down from 20+ minutes to 4-8 minutes. The easy setup and their docker builds with fast caching are really good.

This sounds promising. What made your Rust builds become that fast? Any repo you could point us to?

If you're building rust containers, we have the world's fastest remote container builders with automated caching.

You wouldn't really have to change anything on your dockerfile to leverage this and see significant speed up.

The docs are here: https://docs.warpbuild.com/docker-builders#usage

Re: The Pain That Is GitHub Actions

#442

Post by noplacelikehome »

hi_hi wrote: post #234
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 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…

Nix is awesome for this -- write your entire series of CI tools in she'll or Python and run them locally in the exact same environment as they will run in CI. Add SOPS to bring secrets along for the ride.

Re: The Pain That Is GitHub Actions

#443

Post by noplacelikehome »

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.

There sure is a lot of chest beating

Re: The Pain That Is GitHub Actions

#444

Post by sgarland »

doix wrote: post #187
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 came from the semiconductor industry, where everything was locally hosted Jenkins + bash scripts. The Jenkins job would just launch the bash script that was stored in perforce(vcs), so all you had to do to run things locally was run the same bash script. When I joined my first web SaaS startup I had a bit of a culture shock. Everything was running on 3rd party services with their own proprietary config/language/etc…

> I'm kinda used to it now, but I'm not convinced it's any better.

It’s demonstrably worse.

> The base knowledge of POSIX/Linux/whatever was almost completely useless.

Guarantee you, 99% of the engineering team there doesn’t have that base knowledge to start with, because of:

> There are so many layers of abstraction now that I'm not sure anybody truly understands it all.

Everything is constantly on fire, because everything is a house of cards made up of a collection of XaaS, all of which are themselves houses of cards written by people similarly clueless about how computers actually operate.

I hate all of it.

Re: The Pain That Is GitHub Actions

#445

Post by sgarland »

LukaD wrote: post #293
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…

> [...] use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code I fully agree with the recommendation to use maintainable code. But that effectively rules out shell scripts in my oppinion. CI shell scripts tend to become big ball of mud rather quickly as you run into the limitations of bash. I think most devs only have superficial knowledge of shell scripts, so do yourself a f…

Maybe people should get better at shell, instead. Read the bash / zsh manual. Use ShellCheck.

Re: The Pain That Is GitHub Actions

#446

Post by sgarland »

forrestthewoods wrote: post #119
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…

> pipelines can run locally on a developer machine as well (as much as possible at least) Facts. However I’ll go a step further and say “only implement your logic in a tool that has a debugger”. YAML is the worse. But shell scripts are second worst. Use a real language.

Shell is a very real language, and it has a debugger; it’s called set -x and/or strace.

Re: The Pain That Is GitHub Actions

#447

Post by ruuda »

deng wrote: post #153
qweiopqweiop wrote: post #128

Earlier quoted context omitted.

Can you explain YAML? I've found declarative pipelines with it have been... fine?

YAML is fine for what it is: a markup language. I have no problem with it being used in simple configuration files, for instance. However, CI is not "configured", it is coded. It is simply the wrong tool. YAML was continuously extended to deal with that, so it developed into much more than just "markup", but it grew into this terrible chimera. Once you start using advanced features in GitLab's YAML like anchors and r…

If you have to deal with tools that need to be configured with yaml, give https://rcl-lang.org/ a try! It can be "coded" to avoid duplication, with real variables, functions, and loops. It can show you the result that it evaluates to. It can do debug tracing, and it has a built-in build command to generate files like GitHub Actions workflows from an RCL file.

Re: The Pain That Is GitHub Actions

#448

Post by sgarland »

Marsymars wrote: post #431
raffraffraff wrote: post #100

Earlier quoted context omitted.

It probably depends on your org size and how specialised you are. Right now I dislike GitHub Actions and think that Gitlab CI is way better, but I also don't give it to much thought because it's a once in a blue moon task for me to mess with them. But I would absolutely hate to be a "100% DevOps guy" for a huge organisation that wants me to specialise in this stuff all the time. I think that by the end of week 1 I'd…

I don't mind it per se; to me the problem is then that some devs don't bother with basic debugging steps of CI failures - if anything works locally and fails in CI, their first step is to message me - so instead of being "100% DevOps" I spend a pile of time debugging other devs' local environments.

My favorite is when they post an absolutely massive error message, most of which is utterly unrelated, but also the answer to their problem is contained within it.

Re: The Pain That Is GitHub Actions

#449

Post by JanMa »

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…

Make is definitely just my personal preference. If using bash scripts, Just, Taskfile or something similar works better for you then by all means use it.

The main argument I wanted to make is that it works very well to just use GitHub actions to execute your tool of choice.

Re: The Pain That Is GitHub Actions

#450

Post by sgarland »

normie3000 wrote: post #41
yeswecatan wrote: post #32

Earlier quoted context omitted.

Unfortunately people will use --no-verify to bypass hooks.

I don't understand commit hooks - they're like binding a macro to the MS Word save button to make it conditional.

Because if you haven’t auto-formatted, lined, etc. then it’s a very easy way to do that so you don’t waste time watching CI fail for something stupid like trailing comma placement.

I don’t want to think about formatting, I just want everything to be consistent. A pre commit hook can run those tools for me, and if any changes occurred, it can add them to the commit.

Post reply on HN