4 ms·
An alternate voice here: it took a long time for us to get Bazel (and there's still a lot of headbanging on stuff) but if you want fast CI times, a huge test su
by rtpg 6y ago
An alternate voice here: it took a long time for us to get Bazel (and there's still a lot of headbanging on stuff) but if you want fast CI times, a huge test suite, and not have to deal with like 20 repositories (especially if you want cross-cutting PRs) it's basically the only reasonable tool that will get you there. And yeah, you gotta have someone spend a lot of time with it (maybe comparable to futzing about with some JS webpack spaghetti-code... thing).
I think if you're _not_ using JS (and to a lesser extent, Python), it feels like a no-brainer. Unfortunately it's super oriented around getting build artifacts, which doesn't work so well with Python/JS so you're going to have to fight stuff a bit (though the Bazel Slack channel is filled with pretty helpful people).
Overall I've gotten way madder at the other tooling for being "wrong" more than Bazel itself (lots of people really do random stuff when faced with symlinks for example).
I don't know what the "right" amount of time is, but if you current have 30min+ CI times, this can cut stuff down way more and get you much closer to a nice CI/CD flow.
The thing that kinda kills me is that it feels purposefully obtuse at time (in particular about obsfucating the custom rules stuff, despite it being _the_ way to wrap existing projects nicely). But all the Xooglers who end up writing Bazel clones somehow end up with even more obtuse tools...