Pulumi-Automation-Api on despatches

Use `protoc` bin instead of building from source in `bazel`

Mon, 09 Jun 2025 20:57:53 +0000

I work on a project that uses pulumi automation api, which in turn uses protobuf. I think there are other bits in bazel that also uses it.

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:

``` error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory ```

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 /.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)

```bash devbox add protobuf ```

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

```python package(default_visibility = ["//visibility:public"]) sh_binary( name = "protoc", srcs = ["protoc.sh"], ) # https://github.com/protocolbuffers/protobuf/blob/b4b0e304be5a68de3d0ee1af9b286f958750f5e4/BUILD#L773 proto_lang_toolchain( name = "cc_toolchain", command_line = "--cpp_out=$(OUT)", runtime = ":protoc", visibility = ["//visibility:public"], ) ```

third_party/tools/protoc.sh

```bash #!/bin/env bash protoc "$@" ```

Override protoc

You should now be able to override protoc with:

```bash bazel build --proto_compiler=//third_party/tools:protoc ... ```

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

``` build --proto_compiler=//third_party/tools:protoc ```

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.

Streaming Progress With Pulumi Automation API

Wed, 08 Nov 2023 12:38:32 +0000

When using the pulumi automation API, you lose some of the niceties of the pulumi CLI, like having to set up command line args processing and the output is not as friendly or pretty as before. It also doesn't stream the output - though this one is easier to fix.

This is lifted straight out of their golang example code, so if you're working in another language - you should be able to find the relevant code in the same repo

```go // wire up our update to stream progress to stdout stdoutStreamer := optup.ProgressStreams(os.Stdout) // run the update to deploy our fargate web service res, err := stack.Up(ctx, stdoutStreamer) if err != nil { fmt.Printf("Failed to update stack: %v\n\n", err) } ```

Bazel + Pulumi Automation API. Deploying an inline stack along with Pulumi.[stack].yaml

Tue, 07 Nov 2023 15:57:52 +0000

I believe in CI/CD/CD as in Continuous, integration, delivery and deployment. As part of this, I am setting up a workflow where on merge to develop (or main/trunk), the deployment is triggered automatically. Pulumi deploys the current state of code and infrastructure through GitHub actions and OpenID Connect(OIDC) as part of the GitHub Action.

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`

```wp-block-syntaxhighlighter-code # load etc. go_library( name = "iac_auth", srcs = ["deploy.go"], data = glob([ "Pulumi.*.yaml", ]) + [ "Pulumi.yaml", ], visibility = ["//visibility:public"], deps = [ # dependencies automated with gazelle ], ) ```

`iac_auth/deploy.go`

```wp-block-syntaxhighlighter-code package iac_sync import ( "github.com/pulumi/pulumi/sdk/v3/go/pulumi" ) const moduleName = "auth" func DeployGithubLambda(ctx *pulumi.Context) error { fmt.Println("Deploy") conf := config.Require(ctx, "key") fmt.Printf("conf: %s\n", conf) // Will successfully pick up the value if key is in Pulumi..yaml // Actual deployment code here return nil } ```

`iac/BUILD`

```wp-block-syntaxhighlighter-code # other config including standard config of :iac_lib by gazelle go_binary( name = "iac", args = [ "-iac_auth", "$(location //products/productA/auth/iac_auth)", ], data = [ "//products/gitolink/productA/iac_auth", ], embed = [":iac_lib"], visibility = ["//visibility:public"], ) ```

Worth noting the args bit, which is what we use to identify the path where the Pulumi.yaml and Pulumi..yaml files are:

`iac/main.go`

```wp-block-syntaxhighlighter-code package main import ( "context" "flag" "fmt" iacAuth "github.com/drone-ah/monorepo/products/gitolink/auth/iac_auth" "github.com/pulumi/pulumi/sdk/v3/go/auto" "path/filepath" ) func main() { // Pick up the path from args var iacAuthPath = flag.String("iac_auth", "", "bin for iac_auth") flag.Parse() fmt.Printf("param iac: %s \n", *iacAuthPath) ctx := context.Background() projectName := "gitolink" stackName := "dev" stack, err := auto.NewStackInlineSource(ctx, stackName, projectName, iacAuth.DeployGithubLambda, // Define workdir for locatin of the Pulumi yaml files auto.WorkDir(filepath.Dir(*iacAuthPath))) preview, err := stack.Preview(ctx) fmt.Println(err) fmt.Println(preview) } ```

You might also have to use RLocation (see my previous post about including an artifact in another target for an example of this), though when I tried it, it was missing one of the yaml files and I didn't investigate further.