Expose integrated error tracking to UI and services
What does this MR do?
Makes it possible to render errors stored in GitLab database.
Some background:
- We already have UI in place for rendering errors but it uses sentry API as data source
- Sentry errors are rendered through
Gitlab::ErrorTracking::Error*
models (not AR models, no database) that are built based on json data from sentry API. -
ErrorTracking::ProjectSettings
is doing too much. Its not only "settings" but also used as a middleman for all data taken from Sentry API. - In previous merge requests we introduced integrated error tracking (errors received and stored in GitLab database). But there is no way to see them in UI
What was done:
- Add compatibility methods to
ErrorTracking::Error
,ErrorTracking::ErrorEvent
models so it can be treated like the one coming from Sentry API - Add
integrated
boolean toErrorTracking::ProjectSettings
to alter the behavior. Iftrue
then we use our integrated error tracking instead of sentry API. - Introduce fork in logic so services can query either database or
ErrorTracking::ProjectSettings
for errors depends on feature switch. - Put behind the existing feature flag
integrated_error_tracking
In long-term I hope for:
- We get rid of
Gitlab::ErrorTracking::Error*
classes. We'll useErrorTracking::Error
for everything. - We introduce some abstraction layer so we can get rid of
if/else
condition in services. - We refactor
ErrorTracking::ProjectSettings
to handle only settings. We work with sentry API through some other object.
Issue #329596 (closed). See TODO
section there for more steps
The feature is behind a feature flag
How to test
- Seed error tracking to random project
- Visit the error tracking page of that project
PROJECT_URL/-/error_tracking
bundle exec rake db:seed_fu FILTER=error
Database migrations
rake db:migrate
❯ be rake db:migrate RAILS_ENV=test dzaporozhets@DZ-GitLab-MBP-15
== 20210726134950 AddIntegratedToErrorTrackingSetting: migrating ==============
-- add_column(:project_error_tracking_settings, :integrated, :boolean, {:null=>false, :default=>false})
-> 0.0041s
== 20210726134950 AddIntegratedToErrorTrackingSetting: migrated (0.0042s) =====
== 20210728110654 AddStatusToErrorTrackingError: migrating ====================
-- add_column(:error_tracking_errors, :status, :integer, {:null=>false, :default=>0, :limit=>2})
-> 0.0026s
== 20210728110654 AddStatusToErrorTrackingError: migrated (0.0027s) ===========
rake db:rollback
== 20210728110654 AddStatusToErrorTrackingError: reverting ====================
-- remove_column(:error_tracking_errors, :status)
-> 0.0029s
== 20210728110654 AddStatusToErrorTrackingError: reverted (0.0030s) ===========
== 20210726134950 AddIntegratedToErrorTrackingSetting: reverting ==============
-- remove_column(:project_error_tracking_settings, :integrated)
-> 0.0025s
== 20210726134950 AddIntegratedToErrorTrackingSetting: reverted (0.0026s) =====
Screenshots or Screencasts (strongly suggested)
This merge request does not change the UI. Instead it introduces an alternative data source for existing UI. The end goal is for error tracking pages to look and behave the same for both sentry API and local data.
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) => No documentation yet since you cant activate feature without rails console. Its still in development. -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.)
Edited by Dmytro Zaporozhets (DZ)