Release workflow: ship a real BPF ELF across every target#8
Merged
Conversation
v0.0.1's release.yml used `cross build --release` inside Docker containers that lack rustup + nightly + bpf-linker, so `build.rs` silently fell back to the stub ELF and published binaries carried a zero-byte BPF object. Every attach on a shipped binary would fail with "no BPF ELF embedded in the binary". Restructure into three jobs: 1. `bpf` — builds the BPF ELF once on the host runner (rustup/nightly/ bpf-linker all available), uploads `fast-path.bpf.o` as an artifact. 2. `build` (matrix of 4 targets) — downloads the artifact, sets `PACKETFRAME_BPF_OBJ_PATH` pointing at it (cross forwards the env into the Docker container via `CROSS_CONTAINER_OPTS`), cross-builds userspace which embeds the pre-built ELF verbatim. 3. `publish` — unchanged except for a dry_run gate on workflow_dispatch. New `build.rs` override path (`PACKETFRAME_BPF_OBJ_PATH`): - When set, copies the file into OUT_DIR, verifies ELF magic, sets `packetframe_bpf_built` cfg. Skips the nested-cargo invocation entirely. - Panics on a missing file or non-ELF content — refuse to publish a binary with a broken object rather than silent-stub as the old path did. Added `workflow_dispatch` with a `dry_run: true` default so maintainers can exercise bpf + cross-build from any branch without creating a GitHub release. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
v0.0.1's release.yml used
cross buildinside Docker containers that lack rustup + nightly + bpf-linker.build.rssilently stubbed the BPF ELF, and every shipped binary would failattachwith "no BPF ELF embedded". This PR closes the v0.1.0-tag blocker.Changes
New
build.rsoverride:PACKETFRAME_BPF_OBJ_PATH=<path>release.ymlrestructured into 3 jobs:bpf— builds BPF ELF on the host runner, uploadsfast-path.bpf.oartifact.build(matrix of 4 targets) — downloads the artifact, forwardsPACKETFRAME_BPF_OBJ_PATHinto the cross Docker container viaCROSS_CONTAINER_OPTS, cross-builds userspace.publish— unchanged except for a dry-run gate onworkflow_dispatch.Validation
Triggered the workflow via
workflow_dispatchwithdry_run=trueon this branch (run 24718009128):build BPF ELF— produced a 12,656-byte ELF, uploaded as artifactbuild <target>— each loggedUsing pre-built BPF ELF from PACKETFRAME_BPF_OBJ_PATH (12656 bytes), no stub-fallbackpublish release— correctly skipped viadry_rungateDownloaded the
release-x86_64-unknown-linux-gnuartifact and confirmed the 2.28 MB binary embeds the real BPF ELF.Test plan
PACKETFRAME_BPF_OBJ_PATH=<real-ELF> cargo checkuses override pathRemaining: tag
v0.1.0-rc1post-merge to validate full publish path before taggingv0.1.0.🤖 Generated with Claude Code