Bazel Golang Hello World
Warning: only use if you have a severe need for speed and want to be more productive.
Bazel is seriously amazing. The primary Kubernetes/Kubernetes repository has had Bazel enabled for months, but I had run into problems as far as building with Bazel on my MacBook Pro. The learning curve to use bazel is a bit steep, but once @justinsb and I got it running in kops: Holy Cow Batman! Kops tests and builds are so much faster. When cached, build times are sub-second which took 6 min. Those numbers are no joke.
See this link for information on their logo.
What is Bazel
On February 25th, 2015, a Googler pushed the first comment to the Bazel project, and Google officially Open Sourced the project. Blaze is Google’s closed source build tool and is the predecessor to Bazel.
Bazel is a build tool that replaces using Makefiles or other tools for building
go. Under the hood, it uses
go build; but it is not your average build tool.
make has many different options, Bazel provides many exciting features
including dependency management, and templating with external tools, and the
capability to build containers without docker.
- Speed, speed and more speed, Ferrari-like performance. Because of caching, compilation and unit test speed is ridiculous.
- One tool to rule them all. Bazel supports Go, Java, C++, Android, iOS, on OSX, Linux, and Windows.
- Extensibility. Add plugins and call external tools.
- The tool scales. It handles codebases of any size and integrates into CI. The Kubernetes/Kubernetes repository is a huge repo with multiple containers and binaries.
- Build vendoring for go. We were not able to fully use it in kops because of some challenges, but for other projects it works great. Watch out dep, cause you have a serious competitor.
Using Bazel with Go
- Install Bazel - Instructions are here.
- It is my understanding that you do not even need to install Golang, but it is helpful otherwise. Here are the install instructions for Golang.
Create your project with your source control tool of choice. Inside your project, run the bash script provided here.
Provide the go path for the project. For example:
Here is the script:
The above script creates two files. The “WORKSPACE” file is mandatory for every Bazel project. This file typically contains references to external build rules and project dependencies.
From my example project:
The syntax quite similar to Groovy, and you can see the go dependencies being
added to the Workspace. Continually adding
go_repository rules is one of the
areas that needs some automation, and hopefully be addressed with work on this
The next set of files are called BUILD, or BUILD.bazel.
From Bazel documentation:
By definition, every package contains a BUILD file, which is a short program written in the Build Language. Most BUILD files appear to be little more than a series of declarations of build rules; indeed, the declarative style is strongly encouraged when writing BUILD files.
Here is the BUILD file in the root directory of the example project.
The BUILD and BUILD.bazel files are the continual work in Bazel. Add a new import in go, and you need to update the BUILD file. Add a new go file or test, and yep, update BUILD.bazel. Thankfully the Bazel authors have added Gazelle.
Gazelle Build File Generator
Once you have the project initialized, you can execute
bazel run //:gazelle.
This command will execute
gazelle because the Gazelle rule is defined in the
above BUILD file. Running Gazelle will create various BUILD.bazel files in your
More documentation about Gazelle.
Defining Your Binary File(s)
One thing that Gazelle did not do initially was define a rule to build a binary.
I added the
go_library rules by hand, after Gazelle, generated
Common Bazel Commands
The example Makefile contains the usual suspects for Bazel commands. The usual workflows for development: build, test, and Gazelle for Bazel.
Bazel is powerful. You can do cool things like running external targets, and building containers without docker, a heck of a lot faster than docker does it!
Cross-compiling with Bazel is complicated, and the support for making Linux binaries on OSX is limited. One solution is to use a container such as planter.
I am planning on further posts about using go-bindata and containers with Bazel once we have those fixed in kops.
We need to integrate Bazel into kops testing with Travis. One note, use caching
inside your CI tool. Without caching you loose ALL of Bazel’s performance.
Frankly you may as well use
- Install Bazel
- Run the script or create the Workspace and BUILD files
bazel run //:gazelle
- Define your binaries with Bazel rules
- Enjoy the serious performance
First off thanks to the Bazel team, for such an amazing tool. Thanks to @justinsb for his kopeio/build project. I was able to work through issues for my example, using the project as a base.
@ixby, @bentheelder, and others help on the #bazel Kubernetes slack channel have been invaluable.
Thanks to @jroberts235 for recommending including a basic overview of Bazel.