-
Notifications
You must be signed in to change notification settings - Fork 572
UN-2236 [FEAT] Add build-time PostHog control for on-prem deployments #1615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Added build argument to control PostHog analytics at build time, enabling cloud deployments while disabling for on-prem installations. Changes: - Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile - Defaults to true to maintain cloud behavior - Updated sample.env with PostHog configuration documentation - Default set to false for local development (privacy-first) This provides clean separation between cloud (analytics enabled) and on-prem (analytics disabled) builds without runtime complexity. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Summary by CodeRabbit
WalkthroughThe pull request adds PostHog analytics configuration to the frontend application. An environment variable Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
frontend/sample.env (1)
3-5: Clear documentation for local development defaults.The addition is well-documented and appropriately defaults to
falsefor local development, aligning with the privacy-first principle. Consider adding a note to reference the Docker build argument for context when building containers.Optional: Add a comment referencing the Docker build argument to help developers understand the relationship between local development and container builds:
# Analytics - PostHog (set to false to disable tracking) # Default: false for local development + # Note: Docker production builds default to true; override with REACT_APP_ENABLE_POSTHOG=true for local testing REACT_APP_ENABLE_POSTHOG=false
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to Reviews > Disable Cache setting
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
📒 Files selected for processing (2)
docker/dockerfiles/frontend.Dockerfile(1 hunks)frontend/sample.env(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (1)
docker/dockerfiles/frontend.Dockerfile (1)
26-28: PostHog integration is complete and correctly implemented.All verification checks pass:
Frontend code reads
REACT_APP_ENABLE_POSTHOG: Confirmed infrontend/src/index.jslines 12-24. Initialization is conditional—PostHog only initializes if the environment variable is not exactly"false".Network isolation when disabled: Verified. When
REACT_APP_ENABLE_POSTHOG=false, theposthog.init()call is skipped entirely, preventing any network requests to PostHog endpoints.CI/CD configuration: Production builds use the Dockerfile default (
true), which is correct for cloud deployments. On-prem deployments can override via--build-arg REACT_APP_ENABLE_POSTHOG=falseif needed.PostHog dependency: Present in
package.json(posthog-js ^1.116.5), and the React provider is properly set up with safe null checks inPostHogPageviewTracker.js.
|
|
|
||
| # Analytics - PostHog (set to false to disable tracking) | ||
| # Default: false for local development | ||
| REACT_APP_ENABLE_POSTHOG=false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| REACT_APP_ENABLE_POSTHOG=false | |
| REACT_APP_ENABLE_POSTHOG=true |
@athul-rs the current change would imply that OSS users who are trying the platform will not be tracked in Posthog. Is that fine / expected? We should leave this env as true if we wish to continue to track the OSS user's behaviour
cc: @hari-kuriakose @jaseemjaskp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chandrasekharan-zipstack I think your analysis might be incorrect. Since OSS users use it through containers and we are adding it as true during build time https://github.com/Zipstack/unstract/pull/1615/files#diff-7273696816af1540ab5f0d5b11c273aa396c0615b1eb25af83199637750baeb1R26 it should work as expcected
…#1615) Added build argument to control PostHog analytics at build time, enabling cloud deployments while disabling for on-prem installations. Changes: - Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile - Defaults to true to maintain cloud behavior - Updated sample.env with PostHog configuration documentation - Default set to false for local development (privacy-first) This provides clean separation between cloud (analytics enabled) and on-prem (analytics disabled) builds without runtime complexity. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude <[email protected]>
…#1615) Added build argument to control PostHog analytics at build time, enabling cloud deployments while disabling for on-prem installations. Changes: - Added REACT_APP_ENABLE_POSTHOG build argument to frontend Dockerfile - Defaults to true to maintain cloud behavior - Updated sample.env with PostHog configuration documentation - Default set to false for local development (privacy-first) This provides clean separation between cloud (analytics enabled) and on-prem (analytics disabled) builds without runtime complexity. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude <[email protected]>



What
REACT_APP_ENABLE_POSTHOGbuild argument to frontend Dockerfile with default value oftruesample.envwith PostHog configuration documentation, defaulting tofalsefor local developmentWhy
How
docker/dockerfiles/frontend.Dockerfileto add build argument:ARG REACT_APP_ENABLE_POSTHOG=true(defaults to enabled for cloud)ENV REACT_APP_ENABLE_POSTHOG=${REACT_APP_ENABLE_POSTHOG}to pass value to React buildfrontend/sample.envwith documentation and default value for local development:REACT_APP_ENABLE_POSTHOG=false(privacy-first for local dev)The build argument will be set in the CI/CD workflows (unstract-cloud repo):
REACT_APP_ENABLE_POSTHOG=trueREACT_APP_ENABLE_POSTHOG=falseDuring React build,
process.env.REACT_APP_ENABLE_POSTHOGgets replaced with the literal value, making it a build-time decision (no runtime complexity).Can this PR break any existing features? If yes, please list possible items. If no, please explain why.
No, this PR will not break any existing features:
true, maintaining current cloud behaviorindex.jslogic (if (enablePosthog !== "false")) remains unchanged.envRelevant Docs
Related Issues or PRs
Dependencies Versions / Env Variables
REACT_APP_ENABLE_POSTHOG: New build argument (defaults totruein Dockerfile,falsein sample.env for local dev)Notes on Testing
.envfile (should be disabled)REACT_APP_ENABLE_POSTHOG=truein local.envenables PostHogScreenshots
N/A
Checklist
I have read and understood the Contribution Guidelines.
🤖 Generated with Claude Code