Among other things, Brisk allows you to run tests for your local code changes in the cloud (basically the pay mini test piece but for any test runner)
We also have a sync step much like the one described here and allow users to run one off commands (linters, tsc etc)
how does this work for interactive debugging?
I was going to ask the same about the system in TFA but I might as well ask you :)
That also avoids hacky sync scripts.
They don’t work from your local development env and also work in your CI env.
Mostly Brisk was designed to run your complete test suite on every codes save (ie local save) but it also works great from your CI.
We can run entire test suites in seconds which is performance you don’t get with those systems you named (which are generally for building/compiling)
This is one of the biggest selling points of bazel-like build systems. Like to the extent that, for some changes, bazel can say "even though you changed this source file, I can be 100% certain that that change didn't affect any tests and so I will not run them"
I know Bazel is a build system which distributes builds among remote machines.
In fact using any computer language you can achieve these goals - you just need to program it.
So yes you could probably do all the things with all the things, but Basel does not solve this problem out of the box.
I wonder why stripe didn’t “just use Bazel”.
It's meaningless to say "we can run tests in seconds". You can't run my tests in seconds because they're single threaded and take 10 minutes. The important thing is the speedup, and they got a pretty good speedup. Arguably the nop build/test time is important too but it doesn't look like they measured that.
> Basel does not solve this problem out of the box.
Yes it does.
> I wonder why stripe didn’t “just use Bazel”.
In my experience it's because setting up Bazel is a) more work than setting up some ad-hoc build system (Make or CMake or whatever) and b) difficult to switch to retrospectively. So it only gets used where you have people who are experienced enough to know that you will wish you had started with it, and can convince the inexperienced people that it's worth the effort.
Usually you get too many inexperienced people saying "it's too difficult; we'll be fine with Make".
The one thing to know about Bazel is that it's both incredibly impressive, and also one of the least ergonomic pieces of software ever created. It's very clearly an internal project which was cleaned up and open sourced without any attempt to make it more usable outside of Google.
Bazel's kind of like Kubernetes in a way -- you don't actually get enough benefits to adopt it until you're at a certain point in the company lifecycle, and to get to that point you usually have to build other systems first. Then you have to gradually replace those systems with Bazel.
Err yes they do? Unless you mean something really specific that I'm not getting?