Comment by maratc
5 months ago
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.
5 months ago
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.
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)
1 reply →
I agree, but if there's an architecture gap then locally running CI is not gonna help you to bridge it either.
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?
1 reply →