alt Hacker NewsHow do you internalize it?
Our bazel system is full of custom skylark code so understanding the build means effectively reading a bunch of ad-hoc code written with varying degrees of competence and with confusing dependencies. I’m kinda ashamed I don’t have a deep understanding of a tool I use daily - but every time I try reading the documentation I quickly give up.
Replies
zhengyi13 • yesterday at 7:47 PM
Probably not in the way that you might mean it, but for me (Xoogler, 2010 - 2023) internalizing bazel means:
"Hey, where's your tool's code in $MONOREPO?" "<path/to/stuff>"
Cool:
g4d my-citc-client # moral equivalent to `cd ~/repos/stuff`
blaze run path/to/stuff:target
➕ show 1 reply
ASinclair • yesterday at 8:31 PM
I would recommend learning the various "bazel query" variants starting with a plain "bazel query" https://bazel.build/query/language
The first thing is hermeticity and and what it implies: caching. That if targets are a strict function of inputs, and inputs can be hashed, then you can reliably cache them - including test results!
The second thing is distributed caching. Done right, not only are your test results cached, but CI's test results can be cached too.
The third thing is distributed builds. This only starts to matter in big projects, but compilation is inherently a spiky load and if you can share a big pool of compute between a big pool of engineers, you get higher hardware utilization and lower latency to build artifacts.
The fourth thing, something that isn't really feasible outside big tech, is you could be bazel all the way down in a big monorepo. One of the niftiest things at Google is to be able to put a printf inside a database server and run your client test, and blaze knows that it needs to rebuild the database server and it will do it automatically, so that you can get extra insight at almost any level in the stack.