from Hacker News

Local CI. Sign off on your own work

by lwhsiao on 4/14/25, 1:12 AM with 45 comments

• by politelemon on 4/14/25, 2:35 AM

  This simply creates a passing status in the repo so that the pr can be merged.

  There is no obligation on the dev to actually run the tests locally, so you could just save time by disabling status checks.

  The point of a ci pipeline is that the build ran in a more controlled environment and here is the build log for everyone to see proof.

• by nothrabannosir on 4/14/25, 4:37 AM

  Not to sound like a shill but Nix solves this very elegantly: tests are just a special kind of build (usually with a synthetic output like "echo ok > $out") and can therefore be "cached" like any other build. But because build recipes are deterministic, and Nix uses sandboxed, pure build environments, "caching" is just a special case of "uploading build artifacts". Meaning your cache = build artifact server ("binary store"), and it's shared between everyone (CI, build farm, dev laptops, ..), again because build recipes are deterministic. Meaning: if your laptop (or VM) is the same architecture as your CI you can just run your CI steps locally and push that to the shared store, and your CI will now automatically see the tests have already been run and not run them again. And vice-versa. Across all branches and all collaborators who share that same cache.

  This is all deterministic and doesn't require any human in the loop: the test result is hashed by all of the inputs, so you never accidentally spuriously pass a test locally which shouldn't have.

  It requires almost no setup at all. There are SaaS which make this basically turnkey (cachix, nixbuild.net, garnix, ..). Getting your app to build in Nix in the first place, though? Years of tears.

  Nix lives in this group of tools where "easy things are hard, hard things are easy", and this is a classic example.

• by danpalmer on 4/14/25, 3:33 AM

  Lots of confusion between two things in this thread: 1) is this a good idea? 2) is this a good implementation of the idea?

  Whether this is a good idea has been discussed to death already, but assuming you want this (which most people won't, the readme says as much), is this a good implementation of the idea? Yeah, it is.

  Requiring a CI pass to merge, and a tool to add the CI pass after some unspecified process, seems like a neat, minimal implementation that still prompts the author enough to prevent most accidental misses. Is it complete? Of course not, but checklists don't need to be complete to be useful. Atul Gawande's book "The Checklist Manifesto" talks about this a bit, just the act of asking is often enough to break us out of habits and get us thinking, and will often turn up more issues than are on the checklist itself.

  At Google we have a ton of tooling that amounts to light automation around self-certification. Many checks on PRs (CLs) only require you to say "yes I've done the thing", because that's often sufficient.

• by wavemode on 4/14/25, 2:56 AM

  I could certainly see the appeal of this sort of idea. Once your engineering org gets to a certain size, you can end up spending an eye-watering amount of money on CI compute - spinning up runners and executing thousands of tests for every single commit of every single pull request. That cost could decrease by a lot if, for PRs at least, you could use the dev's local machine instead.

  The three prerequisites in my mind would be, that the CI workflow runs inside a local cluster of VMs (to match a real CI environment), that the results of the CI run are still uploaded and published somewhere, and that it's only used for pull requests (whereas a real CI is still used for the main branch).

• by polygot on 4/14/25, 3:47 AM

  I could _maybe, maybe_ see self-hosted GitHub runners inside of VMs running on developer machines. The VMs would have to be re-created after every request however.

  I don't think this is a great idea, however, as now CI is dependent on my flaky laptop's wifi/internet connection/IP address, has the potential to be contaminated by something running on my machine, build logs can be modified, environment shape/architectures are all different and can't be easily controlled, I now have access to all of the CI secrets and can impersonate the CI, etc.

• by serbrech on 4/14/25, 3:42 AM

  Why not actually running CI on your computer? Most CI system work via an agent, so you can join your laptop as a worker to the CI system?

  https://docs.github.com/en/actions/hosting-your-own-runners/...

  You could "favor" your own laptop as a target runner for the CI when it's your PR for example

  https://docs.github.com/en/actions/writing-workflows/choosin...

• by hiyer on 4/14/25, 3:15 AM

  If this is just running tests locally, it seems deeply flawed - e.g. the tests would work even if I forgot to commit new files.

  OTOH if starting a new container, pulling my branch and then doing everything, it's definitely as good as running on remote CI because it's basically replicating the same behaviour. And it would likely still be much faster since:

  * CI machines are underpowered compared to dev laptops/desktops. e.g. our CI builds run on a container with 4 vCPUs and 16GB RAM. In contrast my laptop has 16 cores and 48 GB RAM

  * docker pull itself takes a relatively long time on CI. If I'm running it locally it would just use the cached layers

• by schneems on 4/14/25, 2:29 AM

  I wrote and released a similar concept in 2012 in response to co-workers constantly breaking my code and not running tests before committing. https://rubygems.org/gems/git_test/

  That was before we had a reliable CI server and let me tell you, fixing the CI server was a much better investment than convincing everyone to run and document their tests locally. The basecamp tool is more polished than what I cobbled together, but I personally won’t be reaching for it any time soon.

• by rtpg on 4/14/25, 3:02 AM

  I do like the idea of a variant of this that also includes some signing and logs that share, well, more of the state involved in this.

  This sort of work would likely mean that test suites would be built in a way to be run in a more diverse sets of environments. That leads to just less brittle tests overall, and hopefully a better foundation to debug things.

• by jatins on 4/14/25, 3:57 AM

  Given how fast dev machines are, doing this might not be a bad idea for small teams _if_ you have some way to ensure reproducible builds/tests. Otherwise I can imagine a lot of "works on my machine" cases

  Though if you are an org of 1000+ engineers working in big monorepos better stick to CI

• by syntaxing on 4/14/25, 2:53 AM

  This might sound crazy to a lot of people, but I actually wish I had the same lint/mypy/flake8 CI from work on my personal projects. I don’t need anything fancy but something on github that’s single click that forces discipline.

• by matthewfcarlson on 4/14/25, 2:44 AM

  I agree with the premise (dev machines are under utilized) but the environment (or lack thereof) of the CI machine is its major selling point. No stupid forgot to add dependency x. Of course it works, you developed it on your machine.

• by kevmo314 on 4/14/25, 3:07 AM

  At that rate you might as well force merge, no? That's equivalent to signing off and doesn't make the CI have a false positive signal when it hasn't actually run.

• by llIIllIIllIIl on 4/14/25, 4:22 AM

  Passes on every undeclared dependency that is available locally but would render the official artifact unusable.

• by arnath on 4/14/25, 2:26 AM

  I’m deeply confused … what does this actually do? Mark your commit as having tests passed?

• by ezyang on 4/14/25, 3:52 AM

  I mean, obviously you want to run the local CI in some isolated way. But it's not such a bad idea for many projects.

  At PyTorch, we have the reverse problem, it's basically infeasible to run the CI locally, you really do need the cloud setup to cover all of the operating system / hardware configurations, and the parallelization in cloud also saves you loads of time.

• by xyst on 4/14/25, 2:56 AM

  Now we are back to "hey bro, it signed off on my computer" :shrug_emoji:

• by thiht on 4/14/25, 6:21 AM

  This misses the point of CI. The CI environment is neutral, one of its goals is to avoid the "it works on my machine" effect. If it doesn’t at least run in a container or a VM, it’s not CI.