4 ms·

Until one of your tools makes a backwards incompatible change, and then boom, your whole git history goes down the memory hole. You've got to vendor everything

by jart 4y ago

Until one of your tools makes a backwards incompatible change, and then boom, your whole git history goes down the memory hole. You've got to vendor everything too. Since with a broken commit you can always have git slide back one commit. But it's much harder to spin up a Docker container with the same distro you were using for every part of the bisect.

ghuntley 4y ago
Nix fixes this. See https://tvl.fyi https://tvl.fyi for experiments with rebuilding goog mono repo infra as nix. Specifically https://code.tvl.fyi https://code.tvl.fyi - which uses josh to serve the mono repro as micro repos. Presenting “views” which have super fast ci/cd implications.
- jart 4y ago
  Cosmopolitan Libc Makefile fixes this. And it does it with plain ordinary GNU Make. https://github.com/jart/cosmopolitan/blob/master/Makefile https://github.com/jart/cosmopolitan/blob/master/Makefile It even has Landlock LSM based sandboxing for strict dependency checking. https://github.com/jart/cosmopolitan/blob/ab301401c71effb0a009776be3417756df89c6dd/third_party/make/job.c#L1629 https://github.com/jart/cosmopolitan/blob/ab301401c71effb0a0... It's faster too. Also GNU Make is what Google used for their mono repo before they switched to Blaze. They basically cited the reason they switched to Blaze as being because they didn't have Landlock. So now that we do, Make is the obvious choice! Disclaimer: Google used to pay me to write the coolest features in Bazel like its system for downloading files. https://github.com/bazelbuild/bazel/commit/ed7ced0018dc5c5ebd6fc8afc7158037ac1df00d https://github.com/bazelbuild/bazel/commit/ed7ced0018dc5c5eb... But I stopped supporting Bazel because they kept breaking git bisect history permantently with backwards incompatible changes.
adrianmsmith 4y ago
If you have the version of everything inside Git (e.g. your docker-compose file references Ubuntu 18 or PostgreSQL 13 or whatever), and if your software now depends on a new version you not only update your software but also the versions in the docker-compose file, then it should be possible to spin up docker for the correct version of everything as part of the bisect.
quickthrower2 4y ago
> You've got to vendor everything too Well I hope people do this Not necessarily have a downloaded carbon copy of every dependency, but at least enough information to recover it. package-lock.json file for example. NB. I added a script to backup node_modules of every CI build. Just for paranoia.

by jart 4y ago

ghuntley 4y ago

Nix fixes this. See https://tvl.fyi https://tvl.fyi for experiments with rebuilding goog mono repo infra as nix. Specifically https://code.tvl.fyi https://code.tvl.fyi - which uses josh to serve the mono repro as micro repos. Presenting “views” which have super fast ci/cd implications.

jart 4y ago
Cosmopolitan Libc Makefile fixes this. And it does it with plain ordinary GNU Make. https://github.com/jart/cosmopolitan/blob/master/Makefile https://github.com/jart/cosmopolitan/blob/master/Makefile It even has Landlock LSM based sandboxing for strict dependency checking. https://github.com/jart/cosmopolitan/blob/ab301401c71effb0a009776be3417756df89c6dd/third_party/make/job.c#L1629 https://github.com/jart/cosmopolitan/blob/ab301401c71effb0a0... It's faster too. Also GNU Make is what Google used for their mono repo before they switched to Blaze. They basically cited the reason they switched to Blaze as being because they didn't have Landlock. So now that we do, Make is the obvious choice! Disclaimer: Google used to pay me to write the coolest features in Bazel like its system for downloading files. https://github.com/bazelbuild/bazel/commit/ed7ced0018dc5c5ebd6fc8afc7158037ac1df00d https://github.com/bazelbuild/bazel/commit/ed7ced0018dc5c5eb... But I stopped supporting Bazel because they kept breaking git bisect history permantently with backwards incompatible changes.

adrianmsmith 4y ago

If you have the version of everything inside Git (e.g. your docker-compose file references Ubuntu 18 or PostgreSQL 13 or whatever), and if your software now depends on a new version you not only update your software but also the versions in the docker-compose file, then it should be possible to spin up docker for the correct version of everything as part of the bisect.

quickthrower2 4y ago

> You've got to vendor everything too Well I hope people do this Not necessarily have a downloaded carbon copy of every dependency, but at least enough information to recover it. package-lock.json file for example. NB. I added a script to backup node_modules of every CI build. Just for paranoia.