Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern CI is too complex and misdirected (2021)

gregoryszorc.com

Post reply on HN
Print view View original

201–207 of 207 posts

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

#201

Post by e1gen-v »

rirze wrote: post #194
e1gen-v wrote: post #65

I’ve been using Pulumi automation in our CI and it’s been really nice. There’s definitely a learning curve with the asynchronous Outputs but it’s really nice for building docker containers and separating pieces of my infra that may have different deployment needs.

This comment is specifically about using CI/CD to deploy infrastructure, right? Or does Pulumi have a framework for general CI/CD?

Pulumi doesn’t have a framework for general CICD but from my experience it shifts the complexity out of the bash/yaml scripts and allows me to express it in python and the I can run unit tests and easily run it locally. Our use case is rather simple though, just a fast api backend and front on ECS.

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

#202

Post by lenkite »

AtlasBarfed wrote: post #30
MathMonkeyMan wrote: post #15

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…

I want my build system to be totally declarative Oh the DSL doesn't support what I need it to do. Can I just have some templating or a little bit of places to put in custom scripts? Congratulations! You now have a turing complete system. And yes, per the article that means you can cryptocurrency mine. Ansible terraform Maven Gradle. Unfortunate fact is that these IT domains (builds and CI) are at a junction of two fa…

No, you keep your build system declarative, but you support a clean plugin API that permits injection into the build lifecycle and allow configuring/invoking the plugin with your DSL.

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

#203

Post by maccard »

MortyWaves wrote: post #95
maccard wrote: post #70

Earlier quoted context omitted.

How does that script handle pushing to ghcr, or pulling an artifact from a previous stage for testing? In my experience these are the bits that fail all the time, and are the most important parts of CI once you go beyond it taking 20/30 seconds to build. A clean build in an ephemeral VM of my project would take about 6 hours on a 16 core machine with 64GB RAM.

To be honest I haven’t really thought about it and it’s definitely something it can’t do, you’d probably need to call their APIs or something. I am fortunate in that the only things I want to reuse is package manager caches.

That’s fair, but surely you must see that’s a very simple build.

The complicated part comes when you have job A that builds and Job B that deploys - they run on two different machine specs so you’re not paying for a 16 core machine to wait for helm apply to wait for 5 minutes - they need somewhere secure to shuffle that artifact around. Their access to that service is likely different to your local access to that service, so you run your build locally and it’s fine but then the build machine doesn’t have write access to the new path you’ve just tested and it fails.

90% of the time these are where I see CI failures

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

#204

Post by forrestthewoods »

CGamesPlay wrote: post #13
forrestthewoods wrote: post #5

> But if your configuration files devolve into DSL, just use a real programming language already. This times a million. Use a real programming language with a debugger. YAML is awful and Starlark isn’t much better.

> Use a real programming language with a debugger. YAML is awful and Starlark isn’t much better. I was with you until you said "Starlark". Starlark is a million times better than YAML in my experience; why do you think it isn't?

My experience with Starlark (buck2) is that it makes the whole system wildly complex and inscrutable.

No one actually knows how it works. It’s an undebuggable nightmare of macros. Everyone copy/pastes a few macros they know work. But one step off the beaten path and you’re doomed.

I hate code that looks like data but is infect code. Be data or be code. Don’t pretend to be both.

I tried adding support for Jai to public buck2. I didn’t even get close. I need static types and a debugger. Just make everything a Rust plugin.

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

#205

Post by michaelmior »

merb wrote: post #137
michaelmior wrote: post #133

Earlier quoted context omitted.

A lot of CI platforms (such as GitHub) spit out a lot of environment variables automatically that can help you with the logic in your build script. If they don't, they should give you a way to set them. One approach is to keep the majority of the logic in your build script and just use the platform-specific stuff to configure the environment for the build script. Of course, as you mention, if you want to do things li…

how can you build your containers in parallel? over multiple machines? I'm not sure that a sh script can do that with github

This is another case where doing this well probably requires some deeper integration. That said, it can be limited to a script that lists the jobs to run, glued together with YAML to launch the jobs, each of which call another script with the appropriate parameters. The majority of the logic still lives in scripts.

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

#206

Post by dijit »

merb wrote: post #169
rcxdude wrote: post #155

Earlier quoted context omitted.

>also humans costs way more money than cloud stuff. I the cloud stuff can be managed in like 1 day per month you dont need a real person, if you have real hardware that day is not enough and you soon need a dedicated person, keeping everything up-to-date, etc. In my experience, I have observed the opposite: companies with on-site infrastructure have been able to manage it in the spare time of a relatively small team…

most of the time the "far more complex setup" is mostly easier than the reimplementation of kubernetes with ansible.

the irony here of course is that Kubernetes is sort of designed to be run on bare-metal.

As a life-long ops person, a lot of the capabilities of kubernetes were things we used to bolt-on. (Like logging a boot ID so that we could track looks easier, service managing, having as little local state as possible so that the workloads are somewhat immutable and nodes can be cycled out, draining machines due to hardware failure (or cordoning them at least) etc;etc;etc)

Cloud came in and made some of those things a little easier I guess, but the value of kubernetes for most people is that they don't have to care about it because the providers give you a one size fits all solution: just don't peek under the hood.

Even the best implementation of Kubernetes (GKE) has a huge amount of waste due to software that has been added to every node and configured wrong.

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

#207

Post by iamcreasy »

0xbadcafebee wrote: post #92

Having two different programs that are almost the same except for one or two differences, is actually better than trying to combine them. Why do you even have a "build system"? Why not just a shell script that runs 'cc -o foo foo.c' ? Because there are more complicated things you want to do, and it would be annoying to write out a long shell script to do them all. So you have a program ('build system') that does the…

This clarified my confusion about CI. Thank you for taking the time to write it!
Post reply on HN