I was adding in a dependency to zig-toml and this is the rule that I used:

Let’s break it down:

• name: Pretty flexible, but you probably want to use the lib name, or the name you would use in the zon file.
• urls: You need the url to the zip file. If you want main - you can click on the button that says Code and at the use the link at the bottom that says “Download ZIP”. GitHub documentation on source code archives has more information as well as details on how to get he url for specific commits etc.
• sha256: When running for the first time, bazel will tell you that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-<hash>". However, for whatever reason, it uses a different format from what you need to use in the MODULES.bazel file. To convert it, you can use:

For a while, it was fine - except that some CI runs would take 15 minutes and we couldn’t quite figure out why.

I finally had to update bazel from 7.x to 8 and in that process (which honestly could have been easier, but oh well), I ran into a problem with compiling protobuf.

Namely, I kept running into this error:

I tried many things but was not able to get past this error. In the end, I was able to narrow it down to devbox/nix and how it messes with the environment that doesn’t quite agree with bazel.

What didn’t work

• installing gcc from devbox
• installing stdenv.cc.cc.lib
• Setting LD_LIBRARY_PATH (to <workspace-dir>/.devbox/nix/profile/default/lib, which is where the devbo version of libstdc++.so.6 is installed by stdenv.cc.cc.lib)
• Using the --action-env=
• rules-nixpkgs

None of which really worked.

Disabling devbox did work, which was at least partly encouraging. I also found a bunch of evidence online around this issue (1, 2, 3, 4, 5). Bazel seems to generally dislike non-system gcc.

A ray of hope

I was just about ready to throw in the towel when ChatGPT, in passing suggested using the protobuf binary directly. I wasn’t even using this binary - it was being pulled in as a dependency and I just needed it to work. I did not need it to be built from source.

Furthermore, I found, from my research into trying to solve this that building protobuf was the likely culprit in the CI taking 15 minutes.

I also remembered that someone else on the team had issues trying to get it to build on a mac at some point.

All in all, it was a problematic piece of software and I was seriously considering switching to opentofu - but they might be using it too.

bin protoc

It was difficult to find decent documentation about how to achieve this though, apart from a partially answered on:

• stackoverflow question,
• google groups for bazel-discuss
  • which also led me to a gitlab repo with some code

These resources gave me just enough to be able to cobble together a working solution, which needs:

Install protoc

The first thing we need is a locally installed protoc bin (I’ll used devbox to install it for consistency across dev environments)

You can add a version specifier for better reproducibility.

Runnable Target

We also need a shell target that will execute this correctly. The bazel flag to override protoc takes a local target, not a bin.

third_party/tools/BUILD.bazel

third_party/tools/protoc.sh

Override protoc

You should now be able to override protoc with:

Having to pass in a flag each time is annoying though, and you can add it to your .bazelrc

Sample code

You can find the sample code in the wordsonsand repo which uses this exact solution to override protoc and get the pulumi sample code to work ;)

PS: It also includes a fully migrated MODULES.bazel with support for golang. You will also want to check out BUILD in the root.

You can add it to your ~/.bazelrc (it needs the path to be absolute)

From our integration tests, we run pulumi stack output (or in some cases pulumi up) through the automation API before we run the tests so that we can

• Confirm that the stack is up
• Get the relevant parameters (actual names of lambdas / dynamo db tables etc.)

However, since we use bazel for our tests, we ran into a small problem in that Bazel (rightly) prevents the tests from writing to anything outside the sandbox. This restrictions results in this error

Unit tests are designed to run as fast as possible, so any slower processes like databases are mocked out. While super helpful and powerful in terms of providing confidence in the software, it should be only one part of the testing strategy.

Integration tests, as is implied runs tests of the different part of the software integrated together. Technically speaking, you can still mock out the database and other slower layers to keep it running quickly. However, there is value in including a database or other slower services in the process to test as them in an automated fashion.

What this does mean though, is that you want to be able to run only the unit tests or run the integration tests as well. You might also want to have smoke tests, which are run on your live production environment.

How

You could define a separate target in your BUILD file with the unit tests and let gazelle automatically build your default test target with all the tests. I found this frustrating to use as I had to keep tweaking the dependencies manually whenever anything changed (which happened often)

Tagging

The easiest way to achieve this for golang and bazel is to tag your source code files. You can do this by adding the following to the top of your integration test files

something_integration_test.go

You can pick any tag name you want instead of integration_test like integration, smoke_test etc.

IDE Support

You will likely need to add this source file into the IDEs build constraints to get the IDE to treat it as a source file. In IntelliJ (IDEA/Goland), you will be warned of this

If you click Edit settings, you can add the tag in

When running gazelle, you want to include the files with these tags

Gazelle

If you have multiple tags, you can separate them with commas. This command will generate a test target with all of the source files and its dependencies

Bazel Integration on test

To run only the unit tests, you test as normal:

To run the integration tests as well, include that tag

Run only Unit Tests

This setup will currently not allow you to run ONLY the integration tests. To be able to do that you'll need to add a unit_test tag to the unit test files so that you can exclude them.

You can then run only the unit tests with

Only the integration tests

Or both:

Simpler gazelle command

You can enable the tags by default in the BUILD file so that you don't have to pass the tags into gazelle each time.

BUILD

You can then just run bazel run //:gazelle which will run with these tags enabled.

Sample Source

You can find sample source code demonstrating this in my github repo, under post/2023/11/separatetests

I used to configure Pulumi to be triggered directly from the build process, but bazel (as far I know), does not support Pulumi. When I used pants, there was a custom module, developed by one of the community members which did support pulumi (You might have to ask in the slack channel if you're interested), but they stopped maintaining it as they moved to the Pulumi Automation API.

I am using Automation API from the start, and configuring a "deployer" per product/project within the monorepo. The intention is for the deployer to be as smart as possible - eventually up-ing only the stacks that have changes since the last time- but that's a way down the line.

Another benefit from the Automation API is to pick up the stack outputs automatically when running integration/e2e tests, making the test configuration smoother.

The first step is to be able to define a stack within a product, hook it into the main iac executable and have it working. My directory structure is roughly as below: While I am using golang as my language of choice, it's probably not hugely different in other languages.

• products
  • productA
    • auth
      • iac_auth
        • BUILD
        • deploy.go
        • Pulumi.dev.yaml
        • Pulumi.yaml
      • OtherAuthModules
    • iac
      • BUILD
      • main.go

iac_auth/BUILD

iac_auth/deploy.go

One of the requirements we have is to build a lambda module and then deploy it. The lambda module is a target being built by Bazel (golang, but shouldn't matter):

We then have the iac module, which should get the built version of the above module, so that it can then upload it into lambda

There are two key parameters here to note:

• args: We generate the path to the target module using //products/productA/module/lambda_module)
• data: We use the data tag to ensure that the built output is included when building/running this target

We then need to use runfiles support within golang to be ablet to identify the correct location for the built binary. The reason this part is complex is to be able to support multiple operating systems. I should caveat that I have only got this working on Linux, but Mac/Win shouldn't be too different.

We use the flag module to retrieve the path passed in as a runtime parameter

We use runfiles.Rlocation to pick up the "real" path to the file, prepending the workspace name to the start. You can define the workspace name in the root WORKSPACE file with workspace(name = "workspace_name")

Finally, resolve the Symlink to get the actual file path

References

There are similar mechanisms to find the rLocation in other languages, a couple of which are described in its design document

There is some documentation in rules_go around accessing go_binary from go_test which I referenced and updated to get the above example

I found the above link from a stackoverflow post about feeding bazel output to another bazel rule

In the open source world, I expect that all things which are accessible as 32bit are also accessible and 64bit and ubuntu makes it automagic enough that everything just works. Yes, I run into problems with closed source software like Flash Player (recently resolved with flash player 10) and the Java Plugin but that is another story. I use Eclipse and wanted to do some performance analysis and benchmarking to find a bottleneck and installed the TPTP plugin; and ran into a problem. It just didn’t work.

To resolve it, I turned to google… In this instance, it turned out to be a distraction and a red-herring. It lead me in the direction of installing libstdc++2.10-glibc2.2_2.95.4-27_i386.deb which was difficult at best since there was only a 32bit version of the package and that wasn’t even in the standard repository.

In the end, digging deeper, I found that it simply missed the following shared object libstdc++.so.5.

All I had to do was install libstdc++5:

and it worked… :-D

Now, I think that ACServer which Eclipse uses to do TPTP should not link to an outdated library but that is another issue…