An error occurred fetching the project authors.
- 01 Jun, 2021 1 commit
-
-
- 23 Apr, 2021 1 commit
-
-
Sean McGivern authored
-
- 30 Mar, 2021 1 commit
-
-
Sean McGivern authored
We want to upgrade the version of the Sentry gem we're currently using to the latest version. However, this makes some breaking changes. One of the biggest for our purposes is that it no longer supports processors - these were classes to pre-process the event hash before sending to Sentry. In the latest version, these are no longer available, but we can still use any logic we like in a custom `before_send` hook. So we can manually chain our existing processors there. However, there's a catch: processors in the current version take an event hash, but the `before_send` hook takes an Event object. (Raven::Event in the current version, Sentry::Event in the new one.) This change adds a feature flag - sentry_processors_before_send - that defaults to off. When it's off, we use the processors as we do now. When it's on: 1. All the processors become no-ops when called as processors. 2. We enable them in a `before_send` chain through a different interface. Because they take a different type of argument, this makes the processors in this change a little ugly. We can tidy that up once we've validated this feature flag in production, even before upgrading the gem. We also add specs to test each processor both with and without the feature flag enabled.
-
- 25 Mar, 2021 2 commits
-
-
Sean McGivern authored
This lets us refactor the processors with some confidence that the end result stays the same.
-
Sean McGivern authored
-
- 09 Feb, 2021 2 commits
-
-
Quang-Minh Nguyen authored
-
-
- 08 Feb, 2021 1 commit
-
-
- 05 Jan, 2021 1 commit
-
-
Heinrich Lee Yu authored
Moves the hook to the before_send so that this would be run for exceptions that are automatically caught by Sentry Raven. This also checks Exception#cause so we handle timeouts that happen in view templates where the exceptions would be wrapped in an ActionView::Template::Error
-
- 23 Oct, 2020 3 commits
-
-
Mehmet Emin INAC authored
To prevent sending some sensitive information, we need to normalize the SQL queries before we send them to Sentry. To do so, we decided to use the gem called `pg_query` which compiles some parts of the PostgreSQL database to make it possible to parse SQL queries.
-
Mehmet Emin INAC authored
-
Mehmet Emin INAC authored
-
- 22 Oct, 2020 1 commit
-
-
Stan Hu authored
This reverts merge request !45724
-
- 21 Oct, 2020 1 commit
-
-
Mehmet Emin INAC authored
To prevent sending some sensitive information, we need to normalize the SQL queries before we send them to Sentry. To do so, we decided to use the gem called `pg_query` which compiles some parts of the PostgreSQL database to make it possible to parse SQL queries.
-
- 20 Oct, 2020 2 commits
-
-
Mehmet Emin INAC authored
-
Mehmet Emin INAC authored
-
- 07 Jul, 2020 1 commit
-
-
Sean McGivern authored
When GitLab reports an exception from Sentry, it adds tags of 'correlation_id', 'locale', and 'program'. This allows further tags to be specified by the administrator in the GITLAB_SENTRY_EXTRA_TAGS environment variable. This variable must be a JSON-encoded hash of tags to send on every Sentry event. If it fails to decode from JSON and convert to a hash, it will simply be empty.
-
- 23 Jun, 2020 1 commit
-
-
Arturo Herrero authored
The plan for RSpec 4.0 is to disable monkey patching, reference: https://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero-monkey-patching-mode https://relishapp.com/rspec/rspec-core/docs/configuration/zero-monkey-patching-mode This commit stops using RSpec monkey patching in several specs.
-
- 11 Jun, 2020 2 commits
-
-
Sean McGivern authored
Sidekiq arguments can contain sensitive data. As with Sentry (in the previous commit), we should no emit sensitive arguments in log files.
-
Sean McGivern authored
Filter out sensitive Sidekiq arguments from being sent to Sentry. By default, only numeric arguments are sent. Overrides are possible for individual worker classes if they have safe non-numeric arguments.
-
- 29 May, 2020 1 commit
-
-
Igor authored
-
- 06 Feb, 2020 1 commit
-
-
Stan Hu authored
If an exception occurred from the API, some parameters from the request may be stored unfiltered in `exceptions_json.log`. We now use our internal parameter filters to ensure they are cleaned before writing them to the logs. Closes https://gitlab.com/gitlab-org/gitlab/issues/202132
-
- 13 Dec, 2019 2 commits
-
-
Aleksei Lipniagov authored
Gitlab::Sentry does not reflect the purpose of the class, it needs more generic name which service-agnostic.
-
Kamil Trzciński authored
Rename methods of Sentry class: - `track_acceptable_exception` => `track_exception`: we just want to capture exception - `track_exception` => `track_and_raise_for_dev_exception`: as said, - `track_and_raise_exception` => we want to capture and re-raise exception Update exception tracking - Remove `extra:` and instead accept hash, - Update documentation to include the best practices, - Remove manual logging of exceptions
-
- 17 Sep, 2019 1 commit
-
-
Yorick Peterse authored
This changes any mention of gitlab-ce to gitlab-foss, and any mention of gitlab-ee to just gitlab.
-
- 22 Aug, 2019 1 commit
-
-
Thong Kuah authored
Using the sed script from https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
-
- 19 Aug, 2019 1 commit
-
-
Alex Kalderimis authored
This allows exceptions to advertise their support for sentry and provide structured data.
-
- 13 May, 2019 1 commit
-
-
Bob Van Landuyt authored
Before this, we were only adding the correlation id to the "acceptable exceptions" which we handle in code. But we need to add it to the default raven context so the information would be available for uncaught exceptions.
-
- 18 Apr, 2019 2 commits
-
-
Andrew Newdigate authored
This change is a fairly straightforward refactor to extract the tracing and correlation-id code from the gitlab rails codebase into the new LabKit-Ruby project. The corresponding import into LabKit-Ruby was in https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1 The code itself remains very similar for now. Extracting it allows us to reuse it in other projects, such as Gitaly-Ruby. This will give us the advantages of correlation-ids and distributed tracing in that project too.
-
Andrew Newdigate authored
This change is a fairly straightforward refactor to extract the tracing and correlation-id code from the gitlab rails codebase into the new LabKit-Ruby project. The corresponding import into LabKit-Ruby was in https://gitlab.com/gitlab-org/labkit-ruby/merge_requests/1 The code itself remains very similar for now. Extracting it allows us to reuse it in other projects, such as Gitaly-Ruby. This will give us the advantages of correlation-ids and distributed tracing in that project too.
-
- 06 Dec, 2018 1 commit
-
-
Kamil Trzciński authored
The Correlation ID is taken or generated from received X-Request-ID. Then it is being passed to all executed services (sidekiq workers or gitaly calls). The Correlation ID is logged in all structured logs as `correlation_id`.
-
- 14 Nov, 2018 1 commit
-
-
Dylan Griffith authored
-
- 17 Apr, 2018 1 commit
-
-
Bob Van Landuyt authored
This adds a method to track errors that can be recovered from in sentry. It is useful when debugging performance issues, or exceptions that are hard to reproduce.
-
- 31 Aug, 2017 1 commit
-
-
Bob Van Landuyt authored
-