Closed patpedrosa closed 6 months ago
@patpedrosa is it just about the support of it, or should all the pages we have now already be added as feature-flags and 'toggelable"
During last couple days this got implemented. but needs to be re-iterated over. (see updated issue)
@johnsmith-gooddollar @sirpy These two commits hold the most stuff around posthog implementation could maybe use a review still
https://github.com/GoodDollar/GoodProtocolUI/commit/21157821a23c0cf5bd4ecca4edd85a29d34c7c22 https://github.com/GoodDollar/GoodProtocolUI/commit/d9a962e952fecadaa90ac181bdb58c586503c60a
@L03TJ3 what is that default api key? if it is ours then rule number 1 is to never put production keys in plain text. the posthog url can also be an env with the posthog as default, specifically that it will need to use reverse proxy, other wise feature flags will not work on privacy oriented browsers like brave or with adblockers
@sirpy yes I know, but I had issues loading in env vars on dev environments and we wanted to go live so I had to make a choice as both you and @johnsmith-gooddollar were not responding
Besides that, since cloudflare is still not set up I could not use vercel to deploy to (prod - and manage secrets/keys there) all of our keys will be removed from any commited code, hopefully within the week
@L03TJ3 removing keys is not enough they stay in the git history forever, thats why you never ever commit secrets
@sirpy that is a practice we have done already for a longer time (see our setup/flow for env.shared etc) once we move to vercel we can maybe choose to update those production keys so the git history doesn't matter anymore
I made vercel reverse proxy a separate issue so moving this to qa/verify on prod
Verified that prod is deployed as expected, remaining issue #512 will be solved in the next 2 days
We need to be able to push features to production in a hidden manner so that we can run internal testing and allow Comms to schedule campaigns independently of our deployments.