fix(build): hermetic netprobe eBPF object build for RBE/publish (#3425) #3511

Merged

mfreeman451 merged 1 commit from fix/netprobe-ebpf-cargo-hermetic into staging

2026-06-01 23:20:52 +00:00

mfreeman451 commented

2026-06-01 23:14:46 +00:00

Owner

Why

The netprobe native add-on bundle ships netprobe_ebpf.o, but the eBPF genrule
(//rust/netprobe/ebpf:netprobe_ebpf_object) shelled out to a host
cargo +nightly -Z build-std=core --target bpfel-unknown-none + host bpf-linker.
With no local/no-remote tag, under --remote_executor (the publish lane) it
dispatched to an RBE worker with no Rust toolchain and died at
cargo is required to build the netprobe eBPF object — blocking the
Publish Native Add-ons run and the netprobe capture e2e.

What

Build the eBPF object hermetically from Bazel-declared inputs only:

MODULE.bazel: pinned nightly rustc/cargo/rust-std/rust-src (2026-05-31)
- a static bpf-linker v0.10.3 (@netprobe_ebpf_* http_archives, sha256-pinned).
  The default stable 1.93.0 rules_rust toolchain is untouched.
build-ebpf-object.sh: rewritten — assembles a scratch sysroot from the pinned
components and builds offline against the committed vendor/ tree with
-Z build-std=core --target bpfel-unknown-none. No host PATH tooling, no network.
vendor/: committed cargo-vendor of the eBPF crate's deps plus the
-Z build-std std deps (cargo vendor --sync <rust-src>/library/Cargo.toml).
assemble_addon_bundle.py: harden the dependency-free YAML fallback parser to
strip inline # comments (it was stricter than the authoritative Go validator,
which masked-then-surfaced a rejection of addons/netprobe/addon.yaml).

Validation (carverauto RBE — the environment that was failing)

bazel build --config=ci //rust/netprobe/ebpf:netprobe_ebpf_object → builds
remotely (1 remote), produces a valid 79952-byte eBPF ELF.
bazel build --config=ci //build/native_addons:netprobe_addon_bundle.linux.amd64.tar.gz
→ assembles with netprobe_ebpf.o + serviceradar-netprobe +
serviceradar-netprobe.service + manifests.

Notes

Spec/design/tasks: openspec/changes/add-hermetic-netprobe-ebpf-build/.
Out of scope (follow-up): multi-arch eBPF — --cfg bpf_target_arch is x86_64;
amd64 (the e2e target) is correct, arm64 is a separate change.

🤖 Generated with Claude Code

## Why The netprobe native add-on bundle ships `netprobe_ebpf.o`, but the eBPF genrule (`//rust/netprobe/ebpf:netprobe_ebpf_object`) shelled out to a **host** `cargo +nightly -Z build-std=core --target bpfel-unknown-none` + host `bpf-linker`. With no `local`/`no-remote` tag, under `--remote_executor` (the publish lane) it dispatched to an RBE worker with no Rust toolchain and died at `cargo is required to build the netprobe eBPF object` — blocking the `Publish Native Add-ons` run and the netprobe capture e2e. ## What Build the eBPF object **hermetically** from Bazel-declared inputs only: - `MODULE.bazel`: pinned nightly `rustc`/`cargo`/`rust-std`/`rust-src` (2026-05-31) + a static `bpf-linker` v0.10.3 (`@netprobe_ebpf_*` `http_archive`s, sha256-pinned). The default stable `1.93.0` rules_rust toolchain is untouched. - `build-ebpf-object.sh`: rewritten — assembles a scratch sysroot from the pinned components and builds **offline** against the committed `vendor/` tree with `-Z build-std=core --target bpfel-unknown-none`. No host `PATH` tooling, no network. - `vendor/`: committed cargo-vendor of the eBPF crate's deps **plus** the `-Z build-std` std deps (`cargo vendor --sync <rust-src>/library/Cargo.toml`). - `assemble_addon_bundle.py`: harden the dependency-free YAML fallback parser to strip inline `#` comments (it was stricter than the authoritative Go validator, which masked-then-surfaced a rejection of `addons/netprobe/addon.yaml`). ## Validation (carverauto RBE — the environment that was failing) - `bazel build --config=ci //rust/netprobe/ebpf:netprobe_ebpf_object` → builds remotely (`1 remote`), produces a valid **79952-byte eBPF ELF**. - `bazel build --config=ci //build/native_addons:netprobe_addon_bundle.linux.amd64.tar.gz` → assembles with `netprobe_ebpf.o` + `serviceradar-netprobe` + `serviceradar-netprobe.service` + manifests. ## Notes - Spec/design/tasks: `openspec/changes/add-hermetic-netprobe-ebpf-build/`. - Out of scope (follow-up): multi-arch eBPF — `--cfg bpf_target_arch` is `x86_64`; amd64 (the e2e target) is correct, arm64 is a separate change. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

Rows
Columns