Live data from Hacker News

Modern CI is too complex and misdirected (2021)

gregoryszorc.com

81–90 of 207 posts

Re: Modern CI is too complex and misdirected (2021)

#81
post #71

Earlier quoted context omitted.

until you have to debug a GH action, especially if it only runs on main or is one of the handful of tasks that are only picked up when committed to main. god help you, and don’t even bother with the local emulators / mocks.

But debugging Jenkins jobs is absolute pain too, in varying ways depending on how the job was defined (clicking through the ui, henerated by something, groovy, pipelines, etc).

Yea, thats really a pain and could be improved.

Are there any Jenkins Gurus out there who can give some tips?

Re: Modern CI is too complex and misdirected (2021)

#82

I'm not sure why no one mentioned it yet, but the CI tool of sourcehut ( https://man.sr.ht/builds.sr.ht/ ) simplifies all of this. It just spins a linux distro of your choice, and executes a very bare bone yml that essentially contains a lot of shell commands, so it's also easy to replicate locally. There are 12 yml keywords in total that cover everything. Other cool things are the ability to ssh in a build if it fai…

A big reason people use actions is because they need to run things on MacOS and Windows.

Re: Modern CI is too complex and misdirected (2021)

#83
How much of this is a result of poorly thought out build systems, which require layer after layer of duct tape? How much is related to chasing "cloud everything" narratives and vendor specific pipelines? Even with the sanest tooling, some individuals will manage to create unhygenic slop. How much of the remainder is a futile effort to defend against these bad actors?

Re: Modern CI is too complex and misdirected (2021)

#85

IMO development is too complex and misdirected in general since we cargo cult FAANG. Need AWS, Azure or GCP deployment? Ever thought about putting it on bare metal yourself? If not, why not? Because it's not best practice? Nonsense. The answer with these things is: it depends, and if your app has not that many users, you can get away with it, especially if it's a B2B or internal app. It's also too US centric. The ide…

Requirements are complex too. Even if you don't need to scale at all, you likely do need zero-downtime deployment, easy rollbacks, server fault tolerance, service isolation... If you put your apps into containers and throw them onto Kubernetes, you get a lot of that "for free" and in a well-known and well-tested way. Hand-rolling even one of those things, let alone all of them together, would take far too much effort…

> you likely do need zero-downtime deployment

I know SaaS businesses that don't as they operate in a single country, within a single timezone and the availability needs to be during business days and business hours.

> easy rollbacks

Yea, I haven't seen exceptions at all on this. So yea.

> server fault tolerance

That really depends. Many B2B or internal apps are fine with a few hours, or even a day, of downtime.

> service isolation

Many companies just have one app and if it's a monolith, then perhaps not.

> Hand-rolling even one of those things

Wow, I see what you're trying to say and I agree. But it really comes across as "if you don't use something like Kubernetes you need to handroll these things yourself." And that's definitely not true. But yea, I don't think that's what you meant to say.

Again, it depends

Re: Modern CI is too complex and misdirected (2021)

#86
post #79
post #75

Earlier quoted context omitted.

Sheesh. I've got a multimillion line modern C++ protect that consists of a large number of dylibs and a few hundred delivered apps. A completely cache-free build is an only few minutes. Incremental and clean (cached) builds are seconds, or hundreds of milliseconds. It sounds like you've got hundreds of millions of lines of code! (Maybe a billion!?) How do you manage that?

It’s a few million lines of c++ combined with content pipelines. Shader compilation is expensive and the tooling is horrible. Our cached builds on CI are 20 minutes from submit to running on steam which is ok. We also build with MSVC so none of the normal ccache stuff works for us, which is super frustrating

Fuck. I write shader compilers.

Re: Modern CI is too complex and misdirected (2021)

#87
The article resonates a lot with me. I've been seeing the transition from Jenkins to Azure DevOps / GitHub Actions (same thing more or less) in the company I'm working at and came to very similar conclusions. The single big Jenkins machine shared by 10+ teams mixing UI configuration from 20 plugins with build systems and custom scripts wasn't great, so it was the right decision to move away from it. However, neither great is the current workflow of write->commit->wait->fail->write... while figuring out the correct YAML syntax of some third party GitHub Action that is required to do something very basic like finding files in a nested folder by pattern.

Take a look at Prefect - https://www.prefect.io/ - as far as I can see, it ticks a lot of the boxes that the author mentions (if you can live with the fact that the API is a Python SDK; albeit a very good one that gives you all the scripting power of Python). Don't be scared away by the buzzwords on the landing page, browsing the extensive documentation is totally worthwhile to learn about all of the features Prefect offers. Execution can either happen on their paid cloud offering or self-hosted on your own physical or cloud premises at no extra cost. The Python SDK is open source.

Disclaimer: I am not affiliated with Prefect in any way.

Re: Modern CI is too complex and misdirected (2021)

#89
post #64

I remember a Rich Hickey talk where he described Datomic, his database. He said "the problem with a database is that it's over there ." By modeling data with immutable "facts" (a la Prolog), much of the database logic can be moved closer to the application. In his case, with Clojure's data structures. Maybe the the problem with CI is that it's over there . As soon as it stops being something that I could set up and r…

Your build should be this: build.bash and that's it (and that can even trigger a container build). I've spent far too much time debugging CI builds that work differently to a local build, and it's always because of extra nonsense added to the CI server somehow. I've yet to find a build in my industry that doesn't yield to this 'pattern'. Your environment setup should work equally on a local machine or a CI/CD server,…

Agreed with this sentiment, but with one minor modification: use a Makefile instead. Recipes are still chunks of shell, and they don’t need to produce or consume any files if you want to keep it all task-based. You get tab-completion, parallelism, a DAG, and the ability to start anywhere on the task graph that you want.

It’s possible to do all of this with a pure shell script, but then you’re probably reimplementing some or all of the list above.

Re: Modern CI is too complex and misdirected (2021)

#90

The most concerning part about modern CI to me is how most of it is running on GitHub Actions, and how GitHub itself has been deprioritizing GitHub Actions maintenance and improvements over AI features. Seriously, take a look at their pinned repo: https://github.com/actions/starter-workflows > Thank you for your interest in this GitHub repo, however, right now we are not taking contributions. > We continue to focus o…

They are instead focusing on Agentic Workflows which used natural language instead of YAML.

https://github.com/githubnext/gh-aw

Post reply on HN