new(envoyproxy.io): Envoy — high-performance edge/service proxy (Bazel build from source)

[tannevaled]

From-source Bazel build of envoy. Heavy CI (1-3h, ~8GB RAM), with a vendored-binary fallback commented at the bottom if CI can't sustain it.

Closes a mainstream coverage gap (was missing vs brew + nixpkgs).

[tannevaled]

Blocker: bazel can't fetch yq from GitHub releases inside the runner sandbox.

Latest run fails at the fetch phase, before any actual compilation:

ERROR: …/bazel/repo.bzl:75:13: An error occurred during the fetch of repository 'envoy_repo':
  fail("yq failed: {}".format(json_result.stderr))
Error in fail: yq failed: execvp(…/.bazel-cache/_bazel_root/.../external/yq/yq, …): No such file or directory

Envoy's bazel rules pull yq from github.com/mikefarah/yq/releases/... via http_archive during MODULE.bazel resolution. Either the download is blocked or the extracted artifact doesn't sit at the path bazel expects (yq_linux_amd64 ≠ yq).

Options to unblock, in increasing complexity:

1. Patch envoy's bazel/repo.bzl to use a system yq (need mikefarah.dev/yq added to pantry first — check if it exists)
2. Pre-seed bazel's external cache with yq before running bazelisk build
3. Add --repository_cache=$BAZEL_CACHE and pre-populate

I'll move this PR to draft until we have one of those in place. The from-source pattern is correct but envoy's bazel chain has too many fetch-from-network steps for the current runner setup. Open to suggestions from anyone who's wrangled envoy CI elsewhere.

[tannevaled]

Took option 1 — patched bazel/repo.bzl to use the pkgx-installed yq via repository_ctx.which("yq") instead of the broken @yq http_archive.

The http_archive download was technically working but bazel placed the artifact at external/yq/yq_linux_amd64 (single binary, not a tarball) while repo.bzl expected external/yq/yq. The sed patch sidesteps the path mismatch entirely.

Added github.com/mikefarah/yq as a build dep — it's the pure-Go yq, already in pantry, no additional fetches. Moving the PR back from draft.

[tannevaled]

Yq patch + workspace_status stub both worked — bazel got 5211 compile actions deep before failing.

Current blocker: envoy uses bazel's @llvm_toolchain hermetic rule which fetches its own clang via http_archive. In our sandbox, that download path resolves but the wrapper script then can't exec the toolchain:

ERROR: …/external/hessian2-codec/hessian2/BUILD:31:11:
  Compiling hessian2/reader.cc failed: (Exit 127): cc_wrapper.sh failed:
  error executing CppCompile command (from target @@hessian2-codec//hessian2:reader_lib)
  external/llvm_toolchain/bin/cc_wrapper.sh -U_FORTIFY_SOURCE
  '--target=x86_64-unknown-linux-gnu' …

Exit 127 = command not found. cc_wrapper.sh is there but the clang it tries to exec from external/llvm_toolchain/bin/clang either isn't downloaded properly (same single-binary http_archive trap as @yq) or doesn't have +x.

This needs a bigger patch than #13046 currently has:

• Either replace @llvm_toolchain references with the pkgx llvm.org install (probably patch via sed in bazel/repository_locations.bzl + bazel/toolchains.bzl)
• Or pre-seed bazel's repository cache with a working clang tarball

Both options are non-trivial. Re-marking as draft until I have a cleaner approach. Open to suggestions if anyone has wrangled this.

[tannevaled]

Update — envoy's `bazel/repo.bzl` reads `BAZEL_LLVM_PATH` and uses a local LLVM install when set (I found it on re-reading the file):

llvm_path = repository_ctx.os.environ.get("BAZEL_LLVM_PATH", "")
local_llvm = "True" if llvm_path else "False"

Added `llvm.org` as a build dep and `export BAZEL_LLVM_PATH={{deps.llvm.org.prefix}}` before invoking bazelisk. No file patching needed — envoy provides this env-var hook on purpose for exactly this case.

This keeps the from-source promise intact: every binary tool in the toolchain now comes from pantry (bazelisk, llvm.org clang, yq), no http_archive fetches of opaque binaries from random GitHub releases.

Marking ready for review.

[tannevaled]

Status update — got the from-source build to ~34% (6382/18507 actions) on linux by clearing several toolchain walls (all in the latest commits). The root difficulty: pkgx ships clang (llvm.org) and libc++ (libcxx.llvm.org) as separate bottles, which fights bazel's --config=libc++.

Walls cleared so far:

1. 'iostream' file not found → depend on the existing libcxx.llvm.org bottle for libc++ (rather than adding it to the core llvm.org bottle).
2. bazel "include path references a path outside of the execution root" for an -isystem /opt/... copt on the exec-config ([for tool]) v8/simdutf compiles → build a unified BAZEL_LLVM_PATH prefix that symlinks the llvm.org tree and overlays libcxx's include/c++/v1 + static archives, so libc++ is a toolchain builtin (no external copt).
3. 'algorithm' file not found → a symlinked clang resolves /proc/self/exe back to the llvm.org bottle (no libc++ there), so copy the real clang driver into the unified prefix.
4. v8 genrules "Genrule spawn cannot be executed" → drop --strategy=Genrule=sandboxed.

Current wall: rules_foreign_cc builds its own GNU make from source, and that ./configure fails "C compiler cannot create executables" — the --config=libc++ static -l%:libc++.a LINKLIBS get forced onto that plain-C configure link test. Likely fix: point rules_foreign_cc at a prebuilt make, or scope the libc++ linklibs off the foreign_cc tool builds. Pausing here; the toolchain approach above is the reusable part.

[tannevaled]

Progress update — got much further (≈6350/18501 actions; the foreign_cc deps nghttp2 and maxmind now build). Additional walls cleared beyond the previous comment:

• static libc++ link: ld.lld: unable to find -l:libc++.a → add -L to the unified prefix lib.
• foreign_cc tool builds (make/pkgconfig/cmake/ninja) failing their own configure under --config=libc++ → register the @rules_foreign_cc//toolchains:preinstalled_*_toolchain set + add gnu.org/make, ninja.
• cmake: command not found / cmake: error while loading shared libraries: libcurl.so.4 in foreign_cc build scripts → forward --action_env=PATH and --action_env=LD_LIBRARY_PATH (+ --host_*).

Current wall (infrastructure-level, pausing here): luajit builds a host tool minilua with the modern pkgx clang, which then needs GLIBC_2.29 — but the CI base image's system glibc is older (host/minilua: /lib/x86_64-linux-gnu/libm.so.6: version 'GLIBC_2.29' not found). This is the same old-CI-base-glibc constraint that limited cockroachdb, not a recipe/config issue — a foreign_cc host tool has to run on the build image during the build, and the image's glibc predates what the pkgx toolchain emits. Fixing it cleanly needs either a newer CI base or targeting/bundling an older glibc for the foreign_cc host-tool builds. All the toolchain-plumbing above (unified llvm+libc++ prefix, copied clang, preinstalled foreign_cc toolchains, forwarded PATH/LD_LIBRARY_PATH) is committed and reusable.