Commit d2b64c37 authored by 🤖 GitLab Bot 🤖's avatar 🤖 GitLab Bot 🤖

Add latest changes from gitlab-org/[email protected]

parent 4560c92a
Pipeline #130259772 passed with stages
in 95 minutes and 4 seconds
......@@ -169,7 +169,7 @@ export default {
const { id, name, username } = state.userData;
const hasEmojiAwardedByCurrentUser = note.award_emoji.filter(
emoji => emoji.name === data.awardName && emoji.user.id === id,
emoji => `${emoji.name}` === `${data.awardName}` && emoji.user.id === id,
);
if (hasEmojiAwardedByCurrentUser.length) {
......
---
title: Detect skipped specs in JUnit reports and set TestCase status
merge_request: 28053
author:
type: fixed
......@@ -798,11 +798,15 @@ that wraps around a query being executed. It is implemented as a module that use
Example: `Present`
```ruby
module Present
#... some code above...
def self.use(schema_definition)
schema_definition.instrument(:field, Instrumentation.new)
module Gitlab
module Graphql
module Present
#... some code above...
def self.use(schema_definition)
schema_definition.instrument(:field, ::Gitlab::Graphql::Present::Instrumentation.new)
end
end
end
end
```
......
......@@ -8,7 +8,7 @@ According to [Open Tracing](https://opentracing.io/docs/overview/what-is-tracing
> monitor applications, especially those built using a microservices architecture. Distributed
> tracing helps to pinpoint where failures occur and what causes poor performance.
Distributed tracing is especially helpful in understanding the lifecycle of a request as it passes
Distributed tracing is especially helpful in understanding the life cycle of a request as it passes
through the different components of the GitLab application. At present, Workhorse, Rails, Sidekiq,
and Gitaly support tracing instrumentation.
......@@ -16,6 +16,38 @@ Distributed tracing adds minimal overhead when disabled, but imposes only small
enabled and is therefore capable in any environment, including production. For this reason, it can
be useful in diagnosing production issues, particularly performance problems.
## Using Correlation IDs to investigate distributed requests
The GitLab application passes correlation IDs between the various components in a request. A
correlation ID is a token, unique to a single request, used to correlate a single request between
different GitLab subsystems (for example, Rails, Workhorse). Since correlation IDs are included in
log output, Engineers can use the correlation ID to correlate logs from different subsystems and
better understand the end-to-end path of a request through the system. When a request traverses
process boundaries, the correlation ID is injected into the outgoing request. This enables
the propagation of the correlation ID to each downstream subsystem.
Correlation IDs are normally generated in the Rails application in response to
certain webrequests. Some user facing systems don't generate correlation IDs in
response to user requests (for example, Git pushes over SSH).
### Developer guidelines for working with correlation IDs
When integrating tracing into a new system, developers should avoid making
certain assumptions about correlation IDs. The following guidelines apply to
all subsystems at GitLab:
- Correlation IDs are always optional.
- Never have non-tracing features depend on the existence of a correlation ID
from an upstream system.
- Correlation IDs are always free text.
- Correlation IDs should never be used to pass context (for example, a username or an IP address).
- Correlation IDs should never be _parsed_, or manipulated in other ways (for example, split).
The [LabKit library](https://gitlab.com/gitlab-org/labkit) provides a standardized interface for working with GitLab's
correlation IDs in the Go programming language. LabKit can be used as a
reference implementation for developers working with tracing and correlation IDs
on non-Go GitLab subsystems.
## Enabling distributed tracing
GitLab uses the `GITLAB_TRACING` environment variable to configure distributed tracing. The same
......
......@@ -47,13 +47,16 @@ module Gitlab
end
def create_test_case(data, args)
if data['failure']
if data.key?('failure')
status = ::Gitlab::Ci::Reports::TestCase::STATUS_FAILED
system_output = data['failure']
attachment = attachment_path(data['system_out'])
elsif data['error']
elsif data.key?('error')
status = ::Gitlab::Ci::Reports::TestCase::STATUS_ERROR
system_output = data['error']
elsif data.key?('skipped')
status = ::Gitlab::Ci::Reports::TestCase::STATUS_SKIPPED
system_output = data['skipped']
else
status = ::Gitlab::Ci::Reports::TestCase::STATUS_SUCCESS
system_output = nil
......
......@@ -4,12 +4,13 @@
module Gitlab
module Git
# Ephemeral (per request) storage for environment variables that some Git
# commands need during internal API calls made from Git push hooks.
# Ephemeral (per request) storage for environment variables that some
# Git commands need during internal API calls made from the Git
# pre-receive push hook.
#
# For example, in pre-receive hooks, new objects are put in a temporary
# $GIT_OBJECT_DIRECTORY. Without it set, the new objects cannot be retrieved
# (this would break push rules for instance).
# See
# https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/object_quarantine.md#gitlab-and-git-object-quarantine
# for more information.
#
# This class is thread-safe via RequestStore.
class HookEnv
......
......@@ -104,6 +104,20 @@ describe Gitlab::Ci::Parsers::Test::Junit do
'Some error'
end
context 'and has skipped' do
let(:testcase_content) { '<skipped/>' }
it_behaves_like '<testcase> XML parser',
::Gitlab::Ci::Reports::TestCase::STATUS_SKIPPED, nil
context 'with an empty double-tag' do
let(:testcase_content) { '<skipped></skipped>' }
it_behaves_like '<testcase> XML parser',
::Gitlab::Ci::Reports::TestCase::STATUS_SKIPPED, nil
end
end
context 'and has an unknown type' do
let(:testcase_content) { '<foo>Some foo</foo>' }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment