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

211–220 of 584 posts

Re: The Pain That Is GitHub Actions

#211

Post by 20thr »

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 spend a lot of time in CI (building https://namespace.so) and I agree with most of this:

- Treat pipelines as code. - Make pipelines parts composable, as code. - Be mindful of vendor lock-in and/or lack of portability (it is a trade-off).

For on-promise: if you're already deeply invested in running your own infrastructure, that seems like a good fit.

When thinking about how we build Namespace -- there are parts that are so important that we just build and run internally; and there are others where we find that the products in the market just bring a tremendous amount of value beyond self-hosting (Honeycomb is a prime example).

Use the tools that work best for you.

Re: The Pain That Is GitHub Actions

#212

Post by tailspin2019 »

xyzal wrote: post #182
stinos wrote: post #175

Earlier quoted context omitted.

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…

I think it was mentioned as a part of the 'Joel test' https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

25 years later and we’re still having to relearn some of his lessons!

Re: The Pain That Is GitHub Actions

#213

Post by tasuki »

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…

> languages with no or very very cheap "compilation" steps (i.e. basically only scripting languages)

This is not true at all. It's fine with Haskell, just cache the dependencies to speed up the build...

Re: The Pain That Is GitHub Actions

#214

Post by dkdbejwi383 »

ironmagma wrote: post #178
dkdbejwi383 wrote: post #154

Earlier quoted context omitted.

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?

I guess I'd disagree that this is "slightly broken". That's just how it works. I don't think there's some universally perfect solution that magically just works all the time and never needs intervention or updating.

Re: The Pain That Is GitHub Actions

#215

Post by terminalbraid »

ahub wrote: post #195

I don't see sourcehut [0] mentionned here. I tested github and gitlab CI, sourcehut is MILES ahead. I'll drop two key features here : - any CI run successful or not, gives you back a ssh URI so you can log into the machine to inspect/tweak/tinker - CI files are NOT in the project's repository. no need to wrangle with your git branches when working on CI anymore [0] : https://man.sr.ht/builds.sr.ht/

> CI files are NOT in the project's repository

I don't use sourcehut, but interpreting what you wrote I'd argue this is an antifeature and would be a dealbreaker for me. CI typically evolves with the underlying code and decoupling that from the code makes it difficult to go backwards. It loses cohesion.

Re: The Pain That Is GitHub Actions

#216

Post by tasuki »

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…

> Things like 10 GB cache limits in GitHub

10,000,000,000 bytes should be enough for anyone! It really is a lot of bytes...

Re: The Pain That Is GitHub Actions

#217

Post by motorest »

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.

I've been using YAML for ages and I never had any issue with it. What do you think is wrong with YAML?

Re: The Pain That Is GitHub Actions

#218

Post by drpossum »

ManBeardPc wrote: post #177

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…

Why even do automated testing too? Devs should just test their code. If they were doing their jobs there would be no bugs./s

Your opinions are so regressive you really should consider going into management.

Re: The Pain That Is GitHub Actions

#219

Post by julienEar »

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…

Completely agree. Keeping CI logic in actual code instead of YAML is a lifesaver. The GitHub Actions security issues just reinforce why self-hosted runners are the way to go.

Re: The Pain That Is GitHub Actions

#220

Post by noworriesnate »

ehansdais wrote: post #111
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…

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've used nuke.build for this in the past. This makes it nice for injecting environment variables into properties and for auto-generating CI YAML to wrap the main commands, but it is a bit of a pain when it comes to scaling the build. E.g. we did infrastructure as code using Pulumi, and that caused the build code to dramatically increase to the point the Nuke script became unwieldy. I wish we had gone the plain C# CLI app from the beginning.
Post reply on HN