Modern CI is too complex and misdirected (2021) • Hacker News Board

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

#181

Post by oftenwrong » Thu, Aug 21, 2025, 12:40 AM UTC

pxc wrote: post #125

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…

You still inevitably need a bunch of CI platform-specific bullshit for determining "is this a pull request? which branch am I running on?", etc. Depending on what you're trying to do and what tools you're working with, you may need such logic both in an accursed YAML DSL and in your build script. And if you want your CI jobs to do things like report cute little statuses, integrate with your source forge's static anal…

There are some very basic tools that can help with portability, such as https://github.com/milesj/rust-cicd-env , but I agree that there is a lot of proprietary, vendor-specific, valuable functionality available in the average "CI" system that you cannot make effective use of with this approach. Still, it's the approach I generally favor for a number of reasons.

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

#182

Post by pxc » Thu, Aug 21, 2025, 1:34 AM UTC

pwnna wrote: post #162

arianvanp wrote: post #149

Earlier quoted context omitted.

Use a modern hermetic build system with remote caching or remote execution. Nix, Bazel, buck, pants. Many options

This is like fighting complexity with even more complexity. Nix and bazel are definitely not close to actually achieving hermetic build at scale. And when they break the complexity increases exponentially to fix.

What's not hermetic with Nix? Are you talking about running with the sandbox disabled, or and macOS quirks? It's pretty damn hard to accidentally depend on the underlying system in an unexpected way with Nix.

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

#183

Post by carom » Thu, Aug 21, 2025, 2:02 AM UTC

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 think you have perfectly described OP's vision. A unification of build systems and CI pipelines.

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

#184

Post by immibis » Thu, Aug 21, 2025, 3:21 AM UTC

reactordev wrote: post #177

XorNot wrote: post #132

Earlier quoted context omitted.

The other rule is that script should run as a user. Solely on that working directory. There are too many scripts like that which start, ask for sudo and then it's off to implementing someones "great idea" about your systems network interfaces.

sudo should not be required to build software. If there’s something you require that requires sudo, it’s a pre-build environment setup on your machine. On the host. Or wherever. It’s not part of the build. If you need credentials, get them from secrets or environment variables.

For use cases like making tar files with contents owned by root, Debian developed the tool "fakeroot", which intercepts standard library functions so that when the build script sets a file to be owned by root and then reads the ownership later, it sees it's owned by root, so it records that in the tar file.

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

#185

Post by wredcoll » Thu, Aug 21, 2025, 4:44 AM UTC

pxc wrote: post #182

pwnna wrote: post #162

Earlier quoted context omitted.

This is like fighting complexity with even more complexity. Nix and bazel are definitely not close to actually achieving hermetic build at scale. And when they break the complexity increases exponentially to fix.

What's not hermetic with Nix? Are you talking about running with the sandbox disabled, or and macOS quirks? It's pretty damn hard to accidentally depend on the underlying system in an unexpected way with Nix.

My experience with nix, at a smaller scale than what you're talking about, is that it only worked as long as every. single. thing. was reimplemented inside nix. Once one thing was outside of nix, everything exploded and writing a workaround was miserable because the nix configuration did not make it easy.

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

#186

Post by wredcoll » Thu, Aug 21, 2025, 4:50 AM UTC

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.

I mean, you can just install kubernetes on your own system. Most of these things that AWS provides exist as services. You get some benefit from AWS running them, but you pay in literal dollars and the invisible complexity they add.

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

#187

Post by KronisLV » Thu, Aug 21, 2025, 6:31 AM UTC

kqr wrote: post #105

KronisLV wrote: post #33

Earlier quoted context omitted.

> Part of the problem, maybe the whole problem, is that we could get it all working and portable and optimized for non-blessed environments, but it still will only be expected to work over there, and so the frog keeps boiling. Build the software inside of containers (or VMs, I guess): a fresh environment for every build, any caches or previous build artefacts explicitly mounted. Then, have something like this, so tho…

This sounds a lot like "use Nix".

I mean, if it's easy enough to actually get your average developer to use it, then sure. In my experience, things that are too hard will just not be done, or at least not properly.

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

#188

Post by rcxdude » Thu, Aug 21, 2025, 6:41 AM UTC

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.

Sure, but for the most part these places just didn't use either. You can go extremely far without any of the things the kubernetes gets you. (And if you want to, you can get some if those things for a lot lower cost than k8s)

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

#189

Post by pxc » Thu, Aug 21, 2025, 6:53 AM UTC

wredcoll wrote: post #185

pxc wrote: post #182

Earlier quoted context omitted.

What's not hermetic with Nix? Are you talking about running with the sandbox disabled, or and macOS quirks? It's pretty damn hard to accidentally depend on the underlying system in an unexpected way with Nix.

My experience with nix, at a smaller scale than what you're talking about, is that it only worked as long as every. single. thing. was reimplemented inside nix. Once one thing was outside of nix, everything exploded and writing a workaround was miserable because the nix configuration did not make it easy.

> every. single. thing. was reimplemented inside nix

That's kinda what hermetic means, though, isn't it? Whether that's painful or not, that's pretty much exactly what GGP was asking for!

> Once one thing was outside of nix, everything exploded and writing a workaround was miserable because the nix configuration did not make it easy.

Nix doesn't make it easy to have Nix builds depend on non-Nix things (this is required for hermeticity), but the other way around is usually less troublesome.

Still, I know what you mean. What languages were you working in?

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

#190

Post by pointlessone » Thu, Aug 21, 2025, 7:54 AM UTC

carom wrote: post #183

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 think you have perfectly described OP's vision. A unification of build systems and CI pipelines.

Except the example of a system OP praises can not be ran locally. Well, it can but it’s a full on docker compose setup with half a dozen microservices.