Let track_event accept objects instead of simple values
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.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #409993 (closed)