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.
At DePaul, I teach two courses: SE 480: Software Architecture I and SE 457: Service-Oriented Architecture. I have been teaching at DePaul since 2017.
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.
Let’s say you are using Bazel to build a C program which links against a system-provided version of libcurl, the multiprotocol file transfer library. What is the best way to link your program against this library within Bazel? This blog post provides an answer to that question.
Read more...
This post describes a pattern for implementing a continuous integration (CI) pipeline using Bazel. This pattern is my starting point whenever I set up a new Bazel-based project in CI, after which I add any project-specific pipeline customizations.
This pipeline is purely about the CI (build to release) stages of a pipeline. A full continuous delivery (CD) pipeline, which includes deployment, will be discussed in a later post.
Read more...
In Bazel, a successful build should be a quiet build. While build failures
should, of course, print ample information to stderr to aide in troubleshooting,
any custom Bazel code you write should not output progress information to stdout
or stderr. Let Bazel be responsible for overall build progress reporting.
Yesterday, I explained how you can wrap a bazel run target with
a sh_binary() to execute arbitrary code both before and after
the run target, which is particularly useful for retrieving secrets
from a secret management system and passing them to the run target.
If you are passing secrets via environment variables that are retrieved
by command-line programs, there’s an even easier way to do it – use the
command rule from Atlassian’s bazel-tools repo and its
raw_environment attribute.
An executable rule which can be executed via bazel run is the natural
way to model interactions with external systems in Bazel such as uploading
build artifacts to a remote artifact repository. For example, imagine
a rules_artifactory ruleset which includes a rule artifactory_push()
executable rule which uploads a compiled .dpkg to an Artifactory
apt repository, or a rules_docker ruleset which has a rule
docker_push() which pushes a Docker image to a remote image repository.
When I first started writing custom Bazel rules, I often created
separate rules for the build and run commands in Bazel. This
was a mistake.
When writing custom rules, you often need to invoke executables with
argument lists. For example, let’s say you are writing a custom rule
that executes gcc to compile a set of input source files. You
could write:
Bazel started on Linux and Mac OS, and most people use Bazel on these platforms exclusively, but Bazel can execute on Windows as well. However, Windows has enough idiosynchatic differences that writing a single, operating-system agnostic rule that executes on both Windows and Linux/Mac is quite hard. Often it is easiest to have the rule detect whether it is running on Windows and execute different behavior.
Read more...When writing a custom rule that generates files, be sure to add prefixes to all filenames so that multiple instances of your rule can be instantiated within the same Bazel package.
Read more...