| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This allows exceptions to advertise their support for sentry
and provide structured data.
|
|
|
|
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.
|
|
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.
|
|
GitLab::Sentry has a program_context method to determine whether a
Sentry exception occurred in Sidekiq or rails. Since we will need
similar functionality for distributed tracing, this change extracts the
program_context method into GitLab.process_name for more general
consumption.
|
|
This reverts commit 3560b11922fd180eea5cafd0e763e0e601c5c4ee.
|
|
This changes `correlation_id` to be `correlation-id` when passed via jobs
|
|
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`.
|
|
|
|
|
|
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.
|
|
including/extending it
|
|
Validate PO files in static analysis
See merge request !13000
|
|
The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.
To fix this:
1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
`Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
like that in several places.
3. Change the initializers to use that new form.
|
|
|
|
Use the EnforcedStyleForMultiline: no_comma option.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Moves program tag into the global configuration since this doesn't
change and since Sidekiq workers get a unique context for each event.
Closes #21410
|
