Add full OBI source to release artifacts

[MrAlias]

Closes #1156

Adds a obi-<version>-source-generated.tar.gz archive to every OBI release. This archive contains the full source tree from the tagged revision plus all generated artifacts that normally require the OBI generation pipeline to produce. Downstream consumers (e.g. opentelemetry-collector-contrib) can use it as a drop-in Go module source without needing Docker, clang, bpf2go, or the Gradle Java agent toolchain.

Motivation

Issue #1156 identified that vendoring OBI — in particular for building a collector distribution with an OBI Receiver — is blocked because the generated BPF object files and Go bindings (~12 MB) are gitignored and not available from a plain git clone or go mod vendor. The options considered in that issue were:

• Commit the generated files on every release (like ebpf-profiler does)
• Find another way to ship them

This PR takes the second approach: rather than polluting the default branch history with large binary blobs, the generated artifacts are bundled into a release archive that downstream consumers can download and use as a local module replacement.

OBI generates several categories of artifacts during its build pipeline that are gitignored and not available from a plain git clone:

• eBPF compiled outputs: *_bpfel.go, *_bpfeb.go, *_bpfel.o, *_bpfeb.o, and *_bpfel.go.d / *_bpfeb.go.d dependency files — produced by bpf2go from C sources via a Docker-based clang toolchain.
• Java agent JAR: pkg/internal/java/embedded/obi-java-agent.jar — produced by Gradle inside a Docker container; only a placeholder string is committed to git.

Any project that vendors or replace-directs OBI as a Go module dependency must either run the full generation pipeline themselves or consume this new archive.

What's in the archive

obi-<version>-source-generated/
├── <full git-archived source tree from tagged commit>
├── pkg/
│   └── internal/
│       ├── ebpf/           # *_bpfel.go, *_bpfeb.go, *.o, *.go.d
│       ├── netolly/ebpf/   # same
│       ├── rdns/ebpf/      # same
│       └── java/
│           └── embedded/
│               └── obi-java-agent.jar   # real JAR, not placeholder

The embedded Node.js fdextractor.js is plain tracked source and is already included by git archive; no special handling is needed.

Changes

scripts/release-source.sh (new)

Standalone bash script that builds the archive:

1. Validates that --release-version resolves to the same commit as HEAD, preventing silent mixing of sources from one ref with generated artifacts from another.
2. Runs git archive for the specified ref into a temp directory.
3. Overlays all *_bpfe[lb].go, *.o, and *.go.d files from pkg/ onto the archived tree.
4. Copies the built Java agent JAR (failing fast if only the placeholder is present, i.e. java-docker-build hasn't been run).
5. Creates the .tar.gz and verifies it contains the expected generated artifacts.
6. Cleans up temp files on exit (unless --debug/-x is set).

The script follows the defensive bash style: strict mode, all globals readonly, all runtime state in local variables, shellcheck-clean with no suppression comments.

Makefile

• New release-source target that depends on docker-generate and java-docker-build, then invokes the script and runs release-checksums.
• release-checksums rewritten in POSIX sh (was using bash arrays and shopt -s nullglob).
• RELEASE_SOURCE_VERSION computed independently from RELEASE_VERSION so the source archive version can be set on its own (defaults to exact tag → current branch → main).

.github/workflows/release.yml

Adds a "Build source-generated release artifacts" step that runs make release-source after the binary artifacts are built. The resulting archive is uploaded alongside the amd64/arm64 tarballs and included in the draft release.

RELEASING.md

Documents the new artifact, updated local build steps, and updated archive-contents table.

How to use this artifact downstream

This is the primary use-case: a downstream project that imports OBI as a Go module but cannot (or does not want to) run the OBI generation pipeline.

#!/usr/bin/env bash
set -euo pipefail

OBI_VERSION="v0.x.y"
ARCHIVE="obi-${OBI_VERSION}-source-generated.tar.gz"
BASE_URL="https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/download/${OBI_VERSION}"

# Download and verify
curl -fsSL "${BASE_URL}/${ARCHIVE}" -o "${ARCHIVE}"
curl -fsSL "${BASE_URL}/SHA256SUMS" | grep "${ARCHIVE}" | sha256sum --check

# Extract
tar -xzf "${ARCHIVE}"

# Wire into go.mod (or other build system)
go mod edit -replace "go.opentelemetry.io/obi=${PWD}/obi-${OBI_VERSION}-source-generated"
go mod tidy

Testing

# Build all release artifacts locally (requires Docker)
make release GOARCH=amd64
make release GOARCH=arm64
make release-source

# The dist/ directory will contain:
# obi-<version>-linux-amd64.tar.gz
# obi-<version>-linux-arm64.tar.gz
# obi-<version>-source-generated.tar.gz
# SHA256SUMS

# Verify the source archive contains generated artifacts
tar -tf dist/obi-*-source-generated.tar.gz | grep '_bpfe[lb]\|obi-java-agent'

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.78%. Comparing base (661cf25) to head (e5350b8).
⚠️ Report is 49 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1378      +/-   ##
==========================================
+ Coverage   43.71%   43.78%   +0.07%     
==========================================
  Files         312      312              
  Lines       33850    33893      +43     
==========================================
+ Hits        14797    14841      +44     
+ Misses      18101    18092       -9     
- Partials      952      960       +8     

Flag	Coverage Δ
integration-test	21.87% <ø> (+0.05%)	⬆️
integration-test-arm	0.00% <ø> (ø)
integration-test-vm-x86_64-5.15.152	?
integration-test-vm-x86_64-6.10.6	?
k8s-integration-test	2.31% <ø> (-0.01%)	⬇️
oats-test	0.00% <ø> (ø)
unittests	44.59% <ø> (-0.05%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

This PR adds a “source + generated outputs” tarball to GitHub Releases so downstream consumers can build OBI without running the generation pipeline themselves.

Changes:

• Add a release-source Makefile target to build obi-<version>-source-generated.tar.gz and expand checksum generation to cover all release archives.
• Update the release GitHub Actions workflow to build and publish the new source-generated archive.
• Update RELEASING.md documentation to describe the new artifact and updated local release steps.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
RELEASING.md	Documents the new source-generated release artifact and updated local build steps.
Makefile	Introduces release-source and updates checksum generation to include all obi-<version>-*.tar.gz archives.
.github/workflows/release.yml	Adds a workflow step to build and attach the new source-generated archive to draft releases.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mmat11]

just to get some context, this doesn't solve the case outlined here #1156 , right?

[MrAlias]

just to get some context, this doesn't solve the case outlined here #1156 , right?

I think it gets us closer to a solution here, I'm not sure it is complete. I'd have to understand the other verdoring workflows better.

I think this gets us closer here based on what I plan to do for the collector contrib distribution. They do not want to bring in the full source history to the project as a submodule. So, instead, I plan to download and expand this artifact locally and treat as vendored source there.

Based on that, it does sound like it would resolve #1156, at least for that workflow. But, I'm not sure if it would solve all. @NimrodAvni78 thoughts?

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[grcevski]

LGTM! Great idea

[MrAlias]

I've updated to have this PR resolve #1156 @mmat11. The closer I looked the more convinced I am that this will solve that problem. Please let me know if you think otherwise.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[NimrodAvni78]

Based on that, it does sound like it would resolve #1156, at least for that workflow. But, I'm not sure if it would solve all. @NimrodAvni78 thoughts

@MrAlias not sure i understand the plan, the collector contrib should download this release archive, (which we will release on each version release) and then import it?
can this release archive be imported via go.mod? or is there another way it will be imported

[mmat11]

I've updated to have this PR resolve #1156 @mmat11. The closer I looked the more convinced I am that this will solve that problem. Please let me know if you think otherwise.

Any project that vendors or replace-directs OBI as a Go module dependency must either run the full generation pipeline themselves or consume this new archive.

If this is the case with the collector, then yes

[MrAlias]

Based on that, it does sound like it would resolve #1156, at least for that workflow. But, I'm not sure if it would solve all. @NimrodAvni78 thoughts

@MrAlias not sure i understand the plan, the collector contrib should download this release archive, (which we will release on each version release) and then import it? can this release archive be imported via go.mod? or is there another way it will be imported

In the collector pipeline the replace statement will be in the manifest (like this). However, a similar approach could be taken using go.mod for any other project that wanted to treat the downloaded source code as a module.