Move Snowplow logic from Gitlab::Tracking module to Gitlab::Tracking::Destinations::Snowplow class
Related #337473 (closed)
Summary
In order to be easy to add a new destination, we should consolidate the logic around the tracking library.
Move Snowplow logic from Gitlab::Tracking module to Gitlab::Tracking::Destinations::Snowplow class
Why?
This is a refactoring so we could add a new destination easier.
We might add as destination the Gitlab Snowplow collector
Details
- The public API for tracking should be accessible through
Gitlab::Tracking
module. - From
Gitlab::Tracking
we should use different destinations likeDestinations::ProductAnalytics
,Destinations::Snowplow
and others - The destination classes should not refer to
Gitlab::Tracking
module, this is creating a circular dependency -
Gitlab::Tracking
module should not have destination-specific logic like snowplow_options
Requirements
-
Gitlab::Tracking
module should be the public API for tracking events and collecting them to multiple destinations
Proposal
- Rename
snoplow_options
method tooptions
fromGitlab::Tracking
module. -
options
method should take the configuration from thesnowplow
tracker - There should be a single source for snowplow configuration and should live in
Gitlab::Tracking::Destinations::Snowplow
- Move
SNOWPLOW_NAMESPACE
constant inGitlab::Tracking::Destinations::Snowplow
class - Remove the circular dependency from
Gitlab::Tracking::Destinations::Snowplow
enabled?
method in the enabled method we should check forGitlab::CurrentSettings.snowplow_enabled?
module Gitlab
module Tracking
module Destinations
class Snowplow < Base
extend ::Gitlab::Utils::Override
...
private
def enabled?
Gitlab::CurrentSettings.snowplow_enabled?
end
Edited by Alina Mihaila