Skip to content

Let track_event accept objects instead of simple values

Jonas Larsen requested to merge 409993-accept-objects-instead-of-simple-values into master

What does this MR do and why?

Currently you have to pass simple values to Gitlab::InternalEvents.track_event like this:

 Gitlab::InternalEvents.track_event(
            MR_USER_CREATE_ACTION,
            user_id: user.id,
            project_id: project.id,
            namespace_id: project.namespace_id
          )

This MR change that, so you call it like this instead:

 Gitlab::InternalEvents.track_event(
            MR_USER_CREATE_ACTION,
            user: user,
            project: project,
            namespace: project.namespace
          )

track_event extract the properties from the named parameters and puts them in the standard context.

Currently values are mapped like below

Value Standard Context Property name
user.id user_id
project.id project_id
namespace.id project_id
namespace.actual_plan_name plan_name

We expect to add is_gitlab_team_member to the standard context. After applying this MR, that setting is_gitlab_team_member from a method on user can be managed entirely inside track_event.

In the future, we want to enable our users to add as many values to their events as they want. We expect that users in general want to add values from a limited number of objects. namespace, project, user, merge_request, pipeline probably covers most of them.

When we implement self-describing events and let users add custom properties to events, we expect it to be useful to use the "dot notation" in the event definitions rather than the "underscore notation" and listing all parameters when invoking track_event.

We are making this change now to avoid having to re-migrate metric that we migrate to Gitlab Internal Events Track.

Known limitations

As we we are only sending a limited set of values in Snowplow event (those in the Standard Context) we have to limit which "unique values" we accept for now. The valid "unique values" is currently limit to user.id, project.id and namespace.id. This it to make sure the metrics are reproducible in the data warehouse.

We expect this limitation when self describing events are introduced.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #409993 (closed)

Edited by Jonas Larsen

Merge request reports