[llvm] [Github][Bazel] Add Workflow to Run Bazel Build (PR #165071)

[Aaron Siddhartha Mondal via llvm-commits]

aaronmondal wrote:

> We can't use custom runner images on the existing premerge infrastructure because we do not have a workaround for [kubernetes-sigs/apiserver-network-proxy#748](https://github.com/kubernetes-sigs/apiserver-network-proxy/issues/748) yet. That shouldn't be a permanent state, but is where we're at currently.
> 
> I don't think this is feasible to do on the free GIthub Actions runners.

Ah sorry for the confusion! For Bazel specifically its possible to use remote execution rather than running locally. I.e. the runner in this workflow just needs to construct the build graph, and can then send that off to one or multiple separate builder machines. This way it doesn't matter too much whether it's a free or a self-hosted runner, because the actual compilation happens elsewhere (e.g. in the same K8s cluster in another container or somewhere else entirely).

The way this works is roughly that the llvm-premerge-runner (or a free runner, kinda doesn't matter too much) invokes the bazel build and then sets `--remote_executor=xxx --remote_cache=yyy`. It then only builds up the compile commands and sends them off to the remote builder(s) to actually run.

The tricky part here is that the entire build needs to be fully hermetic so that the machine that constructs the compile commands (i.e. the free or the llvm-premerge runner) needs to do so with binary-identical tools that match what the remote builders expect. Otherwise even with "the same paths" it would lead to cache misses.

Fortunately that's a fixable toolchain issue and mostly bazel-side configuration that can be layered on top without affecting other workflows/development flows. The "image" i was talking about was the image for such remote builders, not for the runner that invokes this workflow.

https://github.com/llvm/llvm-project/pull/165071