Ever wanted to save a file and have your tests automatically run? How about
restart your webserver when one of the source files change? Look no further.
Install ibazel using one of the 3 methods described below. Then:
$ ibazel build //path/to/my:target
Hack hack hack. Save and your target will be rebuilt.
Right now this repo supports build, test, and run.
Installation
There are several ways to install iBazel, documented below.
Mac (Homebrew)
If you run a mac you can install it from homebrew.
$ brew tap bazelbuild/tap
$ brew install bazelbuild/tap/ibazel
NPM
If you're a JS developer you can install it as a devDependency or by calling npm install directly in your project
$ npm install @bazel/ibazel
Linux
Packages are available for the following distributions:
where $GOOS and $GOARCH are your host OS (e.g., darwin or linux) and architecture (e.g., amd64).
Running a target
By default, a target started with ibazel run will be terminated and restarted
whenever it's notified of source changes. Alternatively, if the build rule for
your target contains ibazel_notify_changes in its tags attribute, then the
command will stay alive and will receive a notification of the source changes on
stdin.
Output Runner
iBazel is capable of producing and running commands from the output of Bazel
commands. If iBazel is run with the flag --run_output then it will check for
a %WORKSPACE%/.bazel_fix_commands.json and if present run any commands that
match the provided regular expressions. For example the commands defined by
the following file will match buildozer commands found in the output and
provide a prompt to run the command as well as invoke bazel run //:gazelle if
it detects a missing import for your go code.
[
{
"regex": "^Check that imports in Go sources match importpath attributes in deps.
Adding the flag --run_output_interactive=false will automatically run the
command without prompting for confirmation. The fields in
.bazel_fix_commands.json are:
regex: a regular expression that will be matched against every line of
output.
backslash \ characters will need to be escaped once for the regex to be
parsed properly.
command: a command that will be run from the workspace root.
args: a list of arguments to provide to the command, with $1 being the
first match group of regex, $2 being the second and so on.
You can disable this feature by adding flag --run_output=false or you can
create a .bazel_fix_commands.json that contains an empty json array, [].
This will additionally disable the notification providing usage instructions on
the first invocation of iBazel.
Profiling
iBazel has a --profile_dev flag which turns on a generated profile output file
about the build process and timing. To use it include this flag in the command line. For example,
ibazel --profile_dev=profile.json run devserver
The profile outfile is in concatenated JSON format. Events are outputted one per line.
Profiler events
Event
Description
Attributes (* optional)
IBAZEL_START
Emitted when iBazel is started as part of the first iteration
type, iteration, time, iBazelVersion, bazelVersion, maxHeapSize, committedHeapSize
SOURCE_CHANGE
A source file change was detected
type, iteration, time, targets, elapsed, change
GRAPH_CHANGE
A build file change was detected
type, iteration, time, targets, elapsed, changes*
RELOAD_TRIGGERED
A livereload was triggered to any listening browsers
type, iteration, time, targets, elapsed, changes*
RUN_START
A run operation started
type, iteration, time, targets, elapsed, changes*
RUN_FAILED
A run operation failed
type, iteration, time, targets, elapsed, changes*
RUN_DONE
A run operation completed successfully
type, iteration, time, targets, elapsed, changes*
BUILD_START
A build operation started
type, iteration, time, targets, elapsed, changes*
BUILD_FAILED
A build operation failed
type, iteration, time, targets, elapsed, changes*
BUILD_DONE
A build operation completed successfully
type, iteration, time, targets, elapsed, changes*
TEST_START
A test operation started
type, iteration, time, targets, elapsed, changes*
TEST_FAILED
A test operation failed
type, iteration, time, targets, elapsed, changes*
TEST_DONE
A test operation completed successfully
type, iteration, time, targets, elapsed, changes*
REMOTE_EVENT
A remote event was received from the browser
type, iteration, time, targets, elapsed, remoteType, remoteTime, remoteElapsed, remoteData
REMOTE_EVENT / PAGE_LOAD
A remote event emitted by the profiler client-side script on the browser's load event. remoteType is PAGE_LOAD.
type, iteration, time, targets, elapsed, remoteType, remoteTime, remoteElapsed, remoteData
Event attributes
Attribute
Type
Description
type
string
Event type.
iteration
string
Unique build iteration key.
time
integer
Time of event.
targets
string[]
List of targets that are being built (Note: this is a complete list and includes targets that were already built prior to an iteration).
elapsed
integer
Elapsed time in ms since the start of the iteration.
change
string
The file changed on a SOURCE_CHANGE or GRAPH_CHANGE event.
changes
string[]
A cumulative list of files changed during a build iteration.
iBazelVersion
string
Version of iBazel that generated this event.
bazelVersion
string
Version of bazel in use.
maxHeapSize
string
Max heap size as reported by Bazel.
committedHeapSize
string
Committed heap size as reported by Bazel.
remoteType
string
Sub-type for REMOTE_EVENT type.
remoteTime
number
Browser time for REMOTE_EVENT type.
remoteElapsed
number
Elapsed time in browser since navigationStart for REMOTE_EVENT type.
remoteData
string
Data sent from browser for REMOTE_EVENT type. This may be in escaped JSON format for some remote events.
Example profile output file
You can find an example profile output JSON file here. Below is the file in pretty print JSON format:
Remote events require the client-side profiling script. If you are using the ts_devserver bazel rule, this script will automatically be included in the development bundle so you don't have to worry about including it. If you're not using ts_devserver for development mode, you can include the following script tag to pull in the client-side profiling script:
The script is served by iBazel on port 30000 by default. If port 30000 is not available, iBazel will attempt to find another available port between 30001 and 30099.
Remote events in the profiler script are sent using the Beacon API. This API is available in Chrome 39, Firefox 31, Edge and Opera 26. It is not available in Internet Explorer or Safari. Browser compatability can be checked here.
If your browser does not support the Beacon API, you will see the following error in the console when including the profiler script: iBazel profiler disabled because Beacon API is not available.
Custom remote events
When the profiler script is loaded, a window.IBazelProfileEvent(eventType, data) public API is made available for generating custom remote events. This function sends a custom REMOTE_EVENT to the iBazel profiler log.
Param
Type
Description
eventType
string
The event type that ends up in the 'remoteType' attribute of the REMOTE_EVENT.
data
any
Optional data associated with the event. This is converted to a string. If it is an object it will be converted to escaped JSON in the profiler log.
Additional notes
Termination
SIGINT has to be sent twice to kill ibazel: once to terminate the subprocess,
and the second time for ibazel itself. Also, ibazel will exit on its own when a
bazel query fails, but it will stay alive when a build, test, or run fails.
We use an exit code of 3 for a signal termination, and 4 for a query failure.
These codes are not an API and may change at any point.
What about the --watchfs flag?
Bazel has a flag called --watchfs which, according to the bazel command-line
help does:
If true, Bazel tries to use the operating system's file watch service for
local changes instead of scanning every file for a change
Unfortunately, this option does not rebuild the project on save like the Bazel
watcher does, but instead queries the file system for a list of files that have
been invalidated since last build and will require reinspection by the Bazel
server.
Big thanks
Google for cross-platform build/test CI instances.