[reillys]

No you can’t.

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)

[Maxious]

I'd suggest you revise your competitor analysis. Bazel definitely has a test command that with remote execution and caching absolutely allows you to run entire test suites in seconds* both locally and in CI eg. https://blog.aspect.build/typescript-with-rbe

[reillys]

This blog post says 2 and a half minutes not seconds.

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”.

[IshKebab]

> This blog post says 2 and a half minutes not seconds.

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".

[nkohari]

Stripe does use Bazel. It just didn't exist before Stripe built some of its own internal systems, but it's gradually replacing ~everything from a build standpoint.

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.

[jvolkman]

Stripe does use Bazel.

https://stripe.com/blog/fast-secure-builds-choose-two

[zrail]

First release of Basel was in 2015 when Stripe was already 5 years old and the progenitor of this tooling was already running with several dozen users.

[IshKebab]

> They don’t work from your local development env and also work in your CI env.

Err yes they do? Unless you mean something really specific that I'm not getting?

[reillys]

To be clear the sync step is used for the test suite execution not only the one off command running - it’s just something we can also easily do because we have a hot env in the cloud

[joshuamorton]

> They don’t work from your local development env and also work in your CI env.

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"