Adin Ćebić

I always find BazelCon to be an exceptional experience, and this year was no exception.

Ever since Swift gained the ability to control warnings via diagnostic groups in SE-0443, we’ve been able to promote specific diagnostic groups to errors.

When writing a Bazel module extension, we sometimes need a way to let the user pass some values to configure things, download binaries from a specified URL, etc.

When running a binary through Bazel with bazel run, we might find ourselves in a situation where it is desirable to wrap it in a “parent” binary or script.

Typically, when writing Bazel rules, we output files as the final step, and that is what we need most of the time.

In the world of Bazel, we prefer to be explicit as much as possible and register actions ahead of time.

I was recently writing about the problem of disk space usage when building with Bazel due to its many caches.

Ever since the advent of coding agents, a lot of engineers have started utilizing Git worktrees and, by extension, multiple Bazel output bases.

Swift’s permissive nature when it comes to module dependencies has always annoyed me and made my life a bit harder than I expected.

When using Bazel within a large monorepo, there comes a time when memory starts becoming a problem, and it is important to be aware of the available tools that can help with diagnosis.

When configuring remote build execution, it is very important to test changes locally so you don’t waste time on CI.

I’ve written about Bazel transitions multiple times: first when demonstrating rule extensions, and then when explaining split transitions.

Bazel has grown significantly since its initial open-source release, and it is hard to keep up with every release.

When writing a rule that executes in the exec configuration, we need to communicate that to Bazel so it doesn’t attempt to build it for the target configuration: generator = rule( implementation = _generator_impl, ..., cfg = "exec", ) While t…

Recently, I have noticed more rulesets adopting Bzlmod-specific features.

Stamping is the act of embedding build metadata into the product that we ship to customers.

Traditionally, when setting up a developer machine, instructions include something like “install the following tools using Homebrew”.

It is well known that macOS Finder .DS_Store files should never be checked in to a repo, or leave the single machine for that matter.

In a quest to speed up Bazel builds we tend to pick every available low-hanging fruit once somebody discovers it.

From time to time, it is worth cleaning up old Bazel stuff in your repositories.

There are many instances where it would be really convenient to run multiple targets at once.

It’s very common to want to apply some Bazel feature only to your first-party repo while omitting external dependencies.

When working on a medium to large iOS app, it can be daunting to constantly rebuild and manually go through app screens just to test your changes.

Typically, Bazel rules execute actions that usually correspond to tool processes on the host OS.

Recently, I worked on developing an Xcode source editor extension that needed to run some of our internal code formatters.

It has become increasingly common for major providers to experience outages—from Git servers being unavailable to failures when downloading external dependencies.

In the Bazel world, we don’t always want it to track all the files in our repository.

There are many security as well as practical reasons why one might need to reconfigure Bazel’s downloading behavior.

Typically, when writing a Bazel rule, we produce outputs using the DefaultInfo provider.

There comes a time when working with Bazel when we want to understand the command-line flags used to build our code.

A couple of articles ago, I touched on Bazel transitions.