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

151–160 of 207 posts

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

#151

Post by mrweasel »

sambuccid wrote: post #50

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…

Sourcehuts build.sr.ht is the best CI system I've used. I really want to give it a go at work as a replacement for our existing Jenkins solution, and I don't even thing that Jenkins is that bad.

Previously I've argued that CI/CD systems need two things, the ability to run bash and secrets management. Today I'd add: The ability to spin up an isolated environment for running the bash script.

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

#152

Post by bluGill »

joelfried wrote: post #118
kstrauser wrote: post #107

Earlier quoted context omitted.

Know what I love in a good build system? Nondeterminism! Who needs coffee when you can get your thrills from stochastic processes. Why settle for just non-repeatable builds when you can have non-repeatable build failures!

Would a smart AI accept such foolishness? I doubt it. It'll still use something deterministic under the hood - it'll just have a conversational abstraction layer for talking to the Product person writing up requirements. We used to have to be able to communicate with other humans to build something. It seems to me that's what they're trying to take out of the loop by doing the things that humans do: talk to other hum…

Would it, or would it rewrite / refactor the logic every time. I'd expect the logic to remain as it for months, but then change suddenly without warning when the AI is upgraded.

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

#153

Post by fireflash38 »

mrbombastic wrote: post #145
reactordev wrote: post #119

Earlier quoted context omitted.

The rule for CI/CD and DevOps in general is boil your entire build process down to one line: ./build.sh If you want to ship containers somewhere, do it in your build script where you check to see if you’re running in “CI”. No fancy pants workflow yamls to vendor lock yourself into whatever CI platform you’re using today, or tomorrow. Just checkout, build w/ params, point your coverage checker at it. This is also the…

How do you get caching of build steps with this approach? Or do you just not?

Even just makefiles have 'caching', provided you set dependencies and output correctly.

A good makefile is really nice to use. Not nice to read or trace unfortunately though.

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

#154

Post by mrweasel »

donatj wrote: post #59

Drone was absolutely perfect back when it was Free Software. Literally "run these commands in this docker container on these events" and basically nothing more. We ran the last fully open source version much longer than we probably should have. When they went commercial, GitHub Actions became the obvious choice, but it's just married to so much weirdness and unpredictability. Whole thing with Drone opened my eyes at…

You and I have very different workflows I think. Drone was probably least intuitive system I've ever used. The idea seems nice, until you learn that Drone pretty much can't do anything useful out of the box. Want to move an artefact between steps, to bad, can't do that (at least you couldn't when we tried it out).

We ended up wrapping everything in a Docker container and back to just running a bash script. Drone had to be used because the architects that be, had decided that Drone was the answer to some question that no one apparently asked.

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

#155

Post by rcxdude »

merb wrote: post #141
taminka wrote: post #39

Earlier quoted context omitted.

many ppl also underestimate how capable modern hardware is: for ~10usd you could handle like a million concurrent connections with a redis cluster on a handful of VPSs...

many ppl also understimate how complex it is to satisfy uptime requirements, how to scale out local infrastructure when storage > 10/50/100tb (yeah a single disk can handle that, but what about bit rot, raid stuff, etc) is involved. it gets worse when you need more servers because your ocr process of course needs cpu x so on a beefiy machine you can handle maybe 50 high page documents. but how do you talk to other ma…

>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 (especially since hardware is pretty powerful and reliable nowadays), while those with cloud infrastruture have a large team focused on just maintaining the system, because cloud pushes you into far more complex setups.

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

#156

Post by alienbaby »

dehrmann wrote: post #143
kstrauser wrote: post #107

Earlier quoted context omitted.

Know what I love in a good build system? Nondeterminism! Who needs coffee when you can get your thrills from stochastic processes. Why settle for just non-repeatable builds when you can have non-repeatable build failures!

What I'm hearing is we need to invent LLM-based compilers.

It's just translation right? Llm's are pretty good at that..

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

#157

Post by kstrauser »

bluGill wrote: post #152
joelfried wrote: post #118

Earlier quoted context omitted.

Would a smart AI accept such foolishness? I doubt it. It'll still use something deterministic under the hood - it'll just have a conversational abstraction layer for talking to the Product person writing up requirements. We used to have to be able to communicate with other humans to build something. It seems to me that's what they're trying to take out of the loop by doing the things that humans do: talk to other hum…

Would it, or would it rewrite / refactor the logic every time. I'd expect the logic to remain as it for months, but then change suddenly without warning when the AI is upgraded.

“Just make it generate YAML and cache that until the prompt changes!”

Orrrrr… just keep that YAML as the sole configuration input in the first place. Use AI to write it if you wish, but then leave it alone.

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

#158

Post by bluGill »

pointlessone wrote: post #98

I can’t say I like OP’s vision. My main objection is that this vision is terminally online. I want to be able to run the whole build locally (for when my internet is down, or I’m on a plane, or on a remote island in a cave, etc.). The local build and CI should only differ in that local build is triggered manually and results are reported in the terminal (or IDE) and CI build is triggered by a push and reported on the…

I want my CI system to track build numbers. When I build locally I don't care about build numbers 99% of the time. There are a number of other things my CI does that I should be able to do locally, but realistically I don't care and so I want to do something different.

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

#159

Post by nlawalker »

jcranmer wrote: post #150
nlawalker wrote: post #144

> CI offerings like GitHub Actions and GitLab Pipelines are more products than platforms because they tightly couple an opinionated configuration mechanism (YAML files) and web UI (and corresponding APIs) on top of a theoretically generic remote execute as a service offering. For me to consider these offerings as platforms, they need to grow the ability to schedule arbitrary compute via an API, without being constrai…

> I wish the author gave more concrete examples about what kinds of workflows they want to dynamically construct and remotely execute (and why a separate step of registering the workflow up front with the service before running it is such a dealbreaker), and what a sufficiently generic and unopinionated definition schema for workflows and tasks would look like as opposed to what a service like GitHub Actions defines.…

I suppose it's just a matter of perspective - I see that as a case for parameterization of a common test-run workflow, not for a one-off definition.

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

#160

Post by bluGill »

I disagree. CI and build systems have different responsibilities and so should be different systems. Both are extremely complex because they have to deal with the complex real world.

Many people have the idea they can make things simpler. Which is really easy because the basic problems are not that hard. Them someone needs "just one more small feature" which seems easy enough and it is - but the combination of everyone's small feature is complex.

Both systems end up having full programming languages because someone really needs that complexity for something weird - likely someone in your project. However don't abuse that power. 99% of what you need from both should be done in a declarative style that lets the system work and is simple. Just because you can do CI in the build system, or the build system's job with the CI system doesn't mean you should. Make sure you separate them.

You CI system should be a small set of entry points. "./do everything" should be your default. But maybe you need a "build", then "test part-a" and "test part-b" as separate. However those are all entry points that your CI system calls to your build system and they are things you can do locally. Can do locally doesn't mean you do - most of the time locally you should be an incremental build. Nothing should be allowed past CI without doing a full build from scratch just to make sure that works (this isn't saying your CI shouldn't do incremental builds for speed - just that it needs to do full rebuilds as well, and if full rebuild breaks you stop everyone until the full rebuild is fixed).

Post reply on HN