Hacker News Reader

This can be achieved by running in CI what commonly runs on local.

E.g. if your build process is simply invoking `build.sh`, it should be trivial to run exactly that in any CI.

This is fine until your run into differences between your machine and the CI one (or you're writing code for a different architecture than the one you're using), but I agree, this is definitely the first step.

I agree, but if there's an architecture gap then locally running CI is not gonna help you to bridge it either.

Plot twist, my build.sh invokes nix build and all I have to do on CI is to install nix and setup caching.

Double plot twist, I need to VPN into a remote network and now all the CI network activity goes through the VPN as well, and some of it gets blocked (true story)

Your builds depend on the consistent behavior of remote servers? That sounds like a recipe for disaster.

Be sure to run it in a container, so you have a semblance of parity.

Where possible. (If your build process builds containers and your tests get them up and make them talk, doing that in a container is a challenge.)

However, there are stateless VMs and stateless BMs too.

What is a BM?

Baremetal (meaning: "the whole server" usually.)

Reply on news.ycombinator.com