chore: attach release info to proguard mapping upload#491
Merged
turnipdabeets merged 2 commits intomainfrom Apr 17, 2026
Merged
chore: attach release info to proguard mapping upload#491turnipdabeets merged 2 commits intomainfrom
turnipdabeets merged 2 commits intomainfrom
Conversation
marandaneto
reviewed
Apr 17, 2026
marandaneto
reviewed
Apr 17, 2026
marandaneto
approved these changes
Apr 17, 2026
Member
marandaneto
left a comment
marandaneto
left a comment
There was a problem hiding this comment.
missing the release label? LGTM
Plumbs applicationId, versionName, and versionCode from the Android variant into the proguard upload task so they are passed to posthog-cli as --release-name, --release-version, and --build. Mirrors the release info already attached on iOS (posthog-ios#558) and React Native (posthog-js). Previously the CLI fell back to git-derived release info (repo name + commit SHA); now uploads are associated with the app's actual release identity, matching how releases show up across SDKs.
turnipdabeets
force-pushed
the
chore/new-cli-params-release-version
branch
from
b08f154 to
72272c7
Compare
AGP exposes an unset versionCode as -1 (its sentinel for missing), not null. The previous implementation passed that through verbatim, producing '--build -1' which the CLI rejects as an unknown flag, breaking proguard uploads for any app that doesn't explicitly declare versionCode. Switch the build property to Int so we can apply Android's platform invariant (versionCode must be ≥ 1) and drop the flag when the value isn't a real build number.
This was referenced May 4, 2026
This was referenced May 4, 2026
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
2 participants
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.
💡 Motivation and Context
The posthog-cli's
exp proguard uploadaccepts--release-name,--release-version, and--build(via flattenedReleaseArgs), but this plugin only passed--pathand--map-id. As a result, proguard uploads either fell back to git-derived release info (repo name + commit SHA) or created no release association at all — not the app's actual release identity.iOS (posthog-ios#558) and React Native (posthog-js) already attach this info on their symbol/sourcemap uploads. This PR brings Android to parity.
💚 How did you test it?
Built
:posthog-samples:posthog-android-sample:assembleReleasetwice against environment 381971:Before:
→ CLI auto-created release
posthog-android@eac1385...(git repo name + commit SHA).After (with
versionCode=2,versionName="1.1"for validation):→ Release associated with the app's actual identity.
Empty-string values from the variant are filtered out so the CLI still falls back to git-derived info when
applicationId/versionName/versionCodearen't set.📝 Checklist
If releasing new changes
pnpm changesetto generate a changeset file