Ignore jitsu_key when snowplow support is enabled
What does this MR do and why?
Currently a projects tracking_key value will use a snowplow instrumentatin_key if it exists, or fall back to a jitsu_key if not. This means when product_analytics_snowplow_support is enabled, there will be no way for a project which is already configured with jitsu to go through the onboarding flow again and change over to snowplow.
This MR updates the tracking_key to check the feature flag. If snowplow_support is enabled, only return the snowplow instrumentation_key. If the flag is not enabled, only return the jitsu_key.
Screenshots or screen recordings
before | after |
---|---|
![]() |
![]() |
product_analytics_snowplow_support
enabled. Project onboarded with Jitsu would previously stay in onboarded state (waiting for events in this example). After the change jitsu_key is ignored so project is back into not-yet-onboarded state.
How to set up and validate locally
Note: This feature has a lot of setup steps. If you need help please ask me or I can step through these during a call with you.
- Follow these instructions to setup Product Analytics in GDK.
- Ensure
product_analytics_snowplow_support
fature flag is disabled - Create a new project, visit Analytics -> Application Analytics, click Set Up on the product analytics item and complete the onboarding with Jitsu
- Enable the
product_analytics_snowplow_support
and drop your gitlab_project_NNN database from clickhouse (simulating what we will do during the rollout) - View the projects Analytics -> Application Analytics again
- Verify the project is back into the not yet onboarded state, and you can complete the onboarding process with Snowplow
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #411829 (closed)