Skip to content

build: add -trimpath to release, container, and goreleaser builds #537

Open

Description

@EricAndrechek

Problem

None of our build paths pass -trimpath, so every binary we ship embeds the absolute filesystem path of the machine that built it. Those paths are baked into the pclntab and surface in any runtime traceback, runtime.Caller result, or panic output.

Concretely:

  • Release binaries (.goreleaser.yaml, builds.wavehouse) carry the CI workspace path, e.g. /home/runner/work/WaveHouse/WaveHouse/internal/ingest/worker.go.
  • Container builds (deployments/Dockerfile:25) carry /src/....
  • Local release builds (scripts/build.sh:67, the single central go build, reached via make build-release) carry whatever directory the contributor happened to be in.
  • go install github.com/Wave-RF/WaveHouse/cmd/wavehouse@latest carries the user's module cache path under their home directory.

Three consequences:

  1. Builds are not reproducible. Identical source compiled in two different directories produces two different binaries. That directly undercuts the build-provenance and attestation work from ci: add build provenance for npm, go binaries, and the ghcr image #308 — we attest to an artifact whose bytes depend on the builder's working directory, so nobody downstream can independently rebuild and compare.
  2. Bug reports leak builder paths. When a user pastes a panic traceback into an issue, every frame carries the build-host path. For our own release binaries that is merely noise; for anyone who builds from source (a documented install path in the README quick start) it means their local directory structure — often including a username or an internal project name — ends up in a public GitHub issue.
  3. Marginally larger binaries, since the path strings are stored per compilation unit.

Worth noting explicitly because it is a common misconception: the existing -s -w ldflags do not cover this. Those strip the symbol table and DWARF, which is what external debuggers read. The file and line data used by Go's own tracebacks lives in the pclntab, which -s -w leaves entirely intact.

Proposed Solution

Add -trimpath to the three release-shaped build paths:

  • .goreleaser.yaml — add a flags: [-trimpath] key to the wavehouse build.
  • deployments/Dockerfile:25 — add -trimpath to the go build invocation.
  • scripts/build.sh — add it to the release mode branch (and cover, so E2E-instrumented binaries match).

Deliberately not the debug mode in scripts/build.sh. -trimpath rewrites source paths to module-relative form, which breaks Delve's ability to resolve sources back to the working tree. Debug builds keep full paths on purpose, consistent with that mode already keeping DWARF and the symbol table.

Verification:

go version -m bin/wavehouse-release | grep -- '-trimpath'   # build setting recorded

and a forced panic should show github.com/Wave-RF/WaveHouse/internal/... rather than an absolute path.

Additional Context

Cheap, no runtime behavior change, no config surface. Pairs naturally with #308 (build provenance) — reproducibility is what makes an attestation independently checkable rather than just signed.

.air.toml is dev-only hot reload and deliberately out of scope.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/infraCI, build, deploy, Docker, releaseenhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions