My name is Steve. I am a Principal Engineer at Relativity and
an Adjunct Professor of Software Engineering at DePaul University.
My primary area of responsibility at Relativity is the storage system behind
RelativityOne, Relativity’s cloud-based software-as-a-service e-Discovery
product. I have designed and implemented a number of components in both the
structured (SQL) and unstructured (object / file) storage backends. Before
Relativity, I worked in the financial industry for 15 years, primarily
for the financal research firm Morningstar. I am a CFA charterholder,
but I rarely use these skills professionally nowadays.
For more about my professional history, please visit my
LinkedIn profile.
I have blogged on-and-off since 2004. Over the last 15+ years,
I have published a number of blog post series and projects
on this website. I also have a number of open source projects
on GitHub.
Downloading a private release asset from GitHub given only its name
and tag requires a complicated series of interactions with the GitHub
API. This blog post explains how to write two repository rules
which make dealing with private release assets in Bazel easy.
Bazel supports scaling out builds with a remote execution system. Unfortunately,
it is very easy for ruleset authors to release rules that work when executed
locally but do not work when executed remotely. This blog post explains ruleset
authors can set up a simple remote execution system to verify that their
rulesets work correctly.
In Bazel, stamping is the process of embedding additional information into built
binaries, such as the source control revision or other workspace-related information.
Rules that support stamping typically include an integer stamp attribute, where
1 means “always stamp”, 0 means “never stamp”, and -1 means “use the Bazel
build --stamp flag. This blog post explains how to write a rule that supports
these values.
Many Bazel attributes support the use of predefined variables
and functions such as @D for output directory or
$(location //foo:bar) to get the path to a label. But what
if you want to apply some sort of tranformation to these
variables, or define your own custom make variables? This
blog post explains how.
Bazel developers are currently working on adding the ability to
retrieve secrets using a credential-helper executable, similar
to how other tools like Docker and Git handle managing secrets.
Until then, the recommended approach is to store secrets in
~/.netrc. This blog post explains how to write a custom Bazel
rule which reads secrets from ~/.netrc.
In general, one should never check in binary artifacts into Git; it is better
to retrieve them from an artifact repository or a website using http_archive().
However, sometimes convenience is more important than ideological purity.
To handle these cases, I wrote a simple workspace rule named local_archive().
When writing Bazel tests using sh_test(), I often find myself needing to compare
two collections for equivalence. For example, I might compare a directory listing
against a set of expected files or directories, or the list of files and directories
in a .tar file against a set of expected items. This blog post provides some tips
and tricks as to how to do so.
Dealing with Bazel runfiles is one of the most annoying things about using Bazel.
Fortunately, Bazel provides a library to make resolving runfiles from Bash scripts
easy.