2021-02-22 17:27:13 +05:30
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
Gitlab::Experiment.configure do |config|
|
2021-10-27 15:23:28 +05:30
|
|
|
# The base experiment class that will be instantiated when using the
|
|
|
|
# `experiment` DSL, is our ApplicationExperiment. If a custom experiment
|
|
|
|
# class is resolvable by the experiment name, that will be instantiated
|
|
|
|
# instead -- which can then inherit from whatever else it wants to.
|
|
|
|
#
|
|
|
|
# Custom experiment classes can be defined in /app/experiments.
|
|
|
|
#
|
2021-02-22 17:27:13 +05:30
|
|
|
config.base_class = 'ApplicationExperiment'
|
2021-10-27 15:23:28 +05:30
|
|
|
|
|
|
|
# Mount the engine and middleware at a gitlab friendly style path.
|
|
|
|
#
|
|
|
|
# The middleware currently focuses only on handling redirection logic, which
|
|
|
|
# is used for instrumenting urls in places where urls are otherwise not
|
|
|
|
# possible to instrument. Emails, and markdown content being among the top
|
|
|
|
# places where this can be useful.
|
|
|
|
#
|
2021-09-30 23:02:18 +05:30
|
|
|
config.mount_at = '/-/experiment'
|
2021-10-27 15:23:28 +05:30
|
|
|
|
|
|
|
# We use a long lived redis cache to increase the performance of experiments.
|
|
|
|
#
|
|
|
|
# Experiments can implement exclusionary and segmentation logic that can be
|
|
|
|
# expensive, and so to better handle these cases, once a variant is assigned
|
|
|
|
# to a given context, it's "sticky" to that context. This cache check is one
|
|
|
|
# of the first things in the process of variant resolution, and so if one is
|
|
|
|
# cached, no further logic is executed in resolving variant assignment.
|
|
|
|
#
|
|
|
|
# This means that there's no easy way to currently move a context from one
|
|
|
|
# variant to another. Future tooling will make this easier, but implementing
|
|
|
|
# a custom cache for your experiment may be required in edge cases.
|
|
|
|
#
|
2021-04-17 20:07:23 +05:30
|
|
|
config.cache = Gitlab::Experiment::Cache::RedisHashStore.new(
|
2021-10-27 15:23:28 +05:30
|
|
|
pool: ->(&block) { Gitlab::Redis::SharedState.with(&block) }
|
2021-04-17 20:07:23 +05:30
|
|
|
)
|
2021-10-27 15:23:28 +05:30
|
|
|
|
|
|
|
# The middleware instruments and redirects urls, but we don't want this to be
|
|
|
|
# exploited or used to send people from a trusted site to a nefarious one. So
|
|
|
|
# we validate urls before redirecting them.
|
|
|
|
#
|
|
|
|
# This behavior doesn't make perfect sense for self managed installs either,
|
|
|
|
# so we don't think we should redirect in those cases.
|
|
|
|
#
|
2022-01-26 12:08:38 +05:30
|
|
|
valid_domains = %w[about.gitlab.com docs.gitlab.com gitlab.com gdk.test localhost]
|
2021-10-27 15:23:28 +05:30
|
|
|
config.redirect_url_validator = lambda do |url|
|
|
|
|
Gitlab.dev_env_or_com? && (url = URI.parse(url)) && valid_domains.include?(url.host)
|
|
|
|
rescue URI::InvalidURIError
|
|
|
|
false
|
|
|
|
end
|
|
|
|
|
|
|
|
# Experiments are instrumented using an event based system by default. This
|
|
|
|
# can be overridden in your experiment by specifying a `#track` method.
|
|
|
|
#
|
|
|
|
# The basic behavior though, is to accept any details and pass them along to
|
|
|
|
# snowplow, with an included gitlab_experiment schema, that has various
|
|
|
|
# details about the experiment, like name and variant assignment.
|
|
|
|
#
|
|
|
|
# This uses the Gitlab::Tracking interface, so arbitrary event properties are
|
|
|
|
# permitted, and will be sent along using Gitlab::Tracking::StandardContext.
|
|
|
|
#
|
2021-09-30 23:02:18 +05:30
|
|
|
config.tracking_behavior = lambda do |action, event_args|
|
|
|
|
Gitlab::Tracking.event(name, action.to_s, **event_args.merge(
|
|
|
|
context: (event_args[:context] || []) << SnowplowTracker::SelfDescribingJson.new(
|
|
|
|
'iglu:com.gitlab/gitlab_experiment/jsonschema/1-0-0', signature
|
|
|
|
)
|
|
|
|
))
|
2021-09-04 01:27:46 +05:30
|
|
|
end
|
2021-02-22 17:27:13 +05:30
|
|
|
end
|