feat(cli): add release-independent event mode to symbol-sets upload

[ablaszkiewicz]

Problem

The default symbol-sets upload always binds the symbol set to a release — from --release-name/--release-version, or from git when you omit them. That has two costs for native apps: the upload needs release coordinates, and the same binary re-binds (and can collide) on every release. There was no way to upload native symbols release-independent and carry the release on the event instead — the native equivalent of the web $release_id.

Changes

Add --release-mode to symbol-sets upload (env POSTHOG_RELEASE_MODE):

• symbol-set (default, unchanged): resolve a release and bind it to every uploaded symbol set.
• event: upload the symbol sets release-independent — bound to no release. One symbol set then serves every release of an unchanged binary, and the upload needs no --release-name/--release-version.

In event mode the release rides the event as $release_id. You name the release with release resolve, pass its id to the app in POSTHOG_RELEASE_ID, and the SDK reports it (PostHog/posthog-rs#239):

# symbols, release-independent — no release name/version here
posthog-cli symbol-sets upload --directory target/release --release-mode=event

# the release is named here, and its id goes to the app
export POSTHOG_RELEASE_ID=$(posthog-cli release resolve --release-name my-app --release-version 1.4.0)
./my-app

This is the same --release-mode=event as the injected variant (#89117), minus the binary patching and code signing: the release still rides the event, but the SDK reads the id from the environment rather than from bytes patched into the build. This pair (this PR + PostHog/posthog-rs#239) and the injection pair (#89117 + PostHog/posthog-rs#237) are alternatives — pick one.

How did you test this code?

Automated (cargo test): parse tests that the flag defaults to symbol-set and accepts event, plus cargo fmt --check and cargo clippy clean.

End to end against a local PostHog stack, run by the agent (Claude). The rust-release-env example is built once; its symbols upload release-independent; two different releases resolve off that one symbol set purely by the reported $release_id.

event-mode upload — release-independent, no release name/version

$ posthog-cli symbol-sets upload --directory target/release --include-source --release-mode=event
INFO  --release-mode=event: uploading symbol sets release-independent; the release is carried on each event as $release_id (POSTHOG_RELEASE_ID)
INFO  Uploading 1 debug symbol file(s)...
INFO  Upload summary: 0 chunk(s) uploaded, 1 skipped (1 already present, 0 too large)
INFO  Debug symbol upload complete

No found release …, no binding — contrast the default mode, where a bare upload resolves a git release and binds the set to it.

name the release, run the app, resolve by id — off the one release-independent symbol set

$ export POSTHOG_RELEASE_ID=$(posthog-cli release resolve --release-name rust-release-env --release-version 3.0.0)
$ ./target/release/rust-release-env
starting — release 01a04269-bf66-0000-2ffa-a6f6d33af9dd (from POSTHOG_RELEASE_ID)
stopping

# read back server-side (dev-login session):
$release_id        : 01a04269-bf66-0000-2ffa-a6f6d33af9dd
$exception_release : { project: "rust-release-env", version: "3.0.0" }

The same binary earlier resolved rust-release-env@1.0.0 off the same symbol set (debug id 8A089A84-…), so one release-independent symbol set serves both releases. Symbolication and release resolution in the UI:

Symbolicated stack trace	Release resolved via the reported $release_id

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Authored by Claude in Claude Code, directed by @ablaszkiewicz (DRI). This is the CLI half of a second, env-variable-based approach to native release tracking, offered alongside the marker-injection pair (#89117 + PostHog/posthog-rs#237) for comparison. It started as docs-only until the DRI pointed out that symbol-sets upload binds the symbol set by default, so event mode was needed here too. The end-to-end verification above was run by the agent against a local PostHog dev stack (ingestion + cymbal); the example data is invented (rust-release-env) and draws on no customer material.

🤖 Generated with Claude Code

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[github-actions]

🤖 CI report

✅ Trunk lane — non-backend lane

This PR is assigned to the non-backend lane. It does not run backend Python tests and may merge in parallel with PRs in other lanes.

[posthog]

🦔 PostHog Review reviewed this pull request

Found 0 must fix, 1 should fix, 1 consider.

Published 2 findings (view the review).

Resolved comments: 1 fixed, 1 left for you

[posthog]

PostHog Review alpha 🦔 If you find any issues helpful - please reply "valid", "invalid", etc., for evaluation purposes 🙏

[posthog]

PostHog Review

Found 1 should fix, 1 consider.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
cli/src/debug_symbols/upload.rs:65
**Event mode resolves plist**

When an event-mode upload supplies a missing or malformed `--info-plist`, `resolve_info_plist()` aborts the command before the release-independent branch runs, preventing otherwise valid symbols from uploading even though this mode does not use release metadata.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "docs(cli): gate release-id env docs to p..." | Re-trigger Greptile}

[ablaszkiewicz]

I think new release mode makes no sense for native technologies with a single-chunk-build - https://posthog.slack.com/archives/C07AA937K9A/p1787845698964179