[server] Track snapshot access requests, and whether they are granted or denied #8374
Conversation
|
/werft run 👍 started the job as gitpod-build-jx-track-snapshot-access.1 |
Codecov Report
@@ Coverage Diff @@
## main #8374 +/- ##
==========================================
- Coverage 12.31% 11.17% -1.14%
==========================================
Files 20 18 -2
Lines 1161 993 -168
==========================================
- Hits 143 111 -32
+ Misses 1014 880 -134
+ Partials 4 2 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
|
Thanks for adding this @jankeromnes |
| @@ -836,6 +836,8 @@ export class GitpodServerImpl implements GitpodServerWithTracing, Disposable { | |||
| ]); | |||
|
|
|||
| if (SnapshotContext.is(context)) { | |||
| // TODO(janx): Remove snapshot access tracking once we're certain that enforcing repository read access doesn't disrupt the snapshot UX. | |||
| this.trackEvent(ctx, { event: "snapshot_access_request", properties: { snapshot_id: context.snapshotId } }).catch(); | |||
There was a problem hiding this comment.
we try to bundle track calls that follow the same context in one call and have differences contained in the properties. in order to follow this here, it would make sense to give the same name to all three track calls (e.g. snapshot_access; we try to follow an object_verb naming convention from the perspective of the user, feel free to come up with something here that follows it more closely). then, you can add a property such as type that contains whether the event is requested, granted or denied so that we still capture the same level of information.
else, this looks good to me!
Description
Track snapshot access requests, and whether they are granted or denied.
Related Issue(s)
Fixes #8340
How to test
Release Notes
Documentation
/werft analytics=segment|TEZnsG4QbLSxLfHfNieLYGF4cDwyFWoe