Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
4560c92ab1
commit
d2b64c37bd
|
|
@ -169,7 +169,7 @@ export default {
|
||||||
const { id, name, username } = state.userData;
|
const { id, name, username } = state.userData;
|
||||||
|
|
||||||
const hasEmojiAwardedByCurrentUser = note.award_emoji.filter(
|
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) {
|
if (hasEmojiAwardedByCurrentUser.length) {
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
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`
|
Example: `Present`
|
||||||
|
|
||||||
```ruby
|
```ruby
|
||||||
module Present
|
module Gitlab
|
||||||
|
module Graphql
|
||||||
|
module Present
|
||||||
#... some code above...
|
#... some code above...
|
||||||
|
|
||||||
def self.use(schema_definition)
|
def self.use(schema_definition)
|
||||||
schema_definition.instrument(:field, Instrumentation.new)
|
schema_definition.instrument(:field, ::Gitlab::Graphql::Present::Instrumentation.new)
|
||||||
|
end
|
||||||
|
end
|
||||||
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
|
> monitor applications, especially those built using a microservices architecture. Distributed
|
||||||
> tracing helps to pinpoint where failures occur and what causes poor performance.
|
> 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,
|
through the different components of the GitLab application. At present, Workhorse, Rails, Sidekiq,
|
||||||
and Gitaly support tracing instrumentation.
|
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
|
enabled and is therefore capable in any environment, including production. For this reason, it can
|
||||||
be useful in diagnosing production issues, particularly performance problems.
|
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
|
## Enabling distributed tracing
|
||||||
|
|
||||||
GitLab uses the `GITLAB_TRACING` environment variable to configure distributed tracing. The same
|
GitLab uses the `GITLAB_TRACING` environment variable to configure distributed tracing. The same
|
||||||
|
|
|
||||||
|
|
@ -47,13 +47,16 @@ module Gitlab
|
||||||
end
|
end
|
||||||
|
|
||||||
def create_test_case(data, args)
|
def create_test_case(data, args)
|
||||||
if data['failure']
|
if data.key?('failure')
|
||||||
status = ::Gitlab::Ci::Reports::TestCase::STATUS_FAILED
|
status = ::Gitlab::Ci::Reports::TestCase::STATUS_FAILED
|
||||||
system_output = data['failure']
|
system_output = data['failure']
|
||||||
attachment = attachment_path(data['system_out'])
|
attachment = attachment_path(data['system_out'])
|
||||||
elsif data['error']
|
elsif data.key?('error')
|
||||||
status = ::Gitlab::Ci::Reports::TestCase::STATUS_ERROR
|
status = ::Gitlab::Ci::Reports::TestCase::STATUS_ERROR
|
||||||
system_output = data['error']
|
system_output = data['error']
|
||||||
|
elsif data.key?('skipped')
|
||||||
|
status = ::Gitlab::Ci::Reports::TestCase::STATUS_SKIPPED
|
||||||
|
system_output = data['skipped']
|
||||||
else
|
else
|
||||||
status = ::Gitlab::Ci::Reports::TestCase::STATUS_SUCCESS
|
status = ::Gitlab::Ci::Reports::TestCase::STATUS_SUCCESS
|
||||||
system_output = nil
|
system_output = nil
|
||||||
|
|
|
||||||
|
|
@ -4,12 +4,13 @@
|
||||||
|
|
||||||
module Gitlab
|
module Gitlab
|
||||||
module Git
|
module Git
|
||||||
# Ephemeral (per request) storage for environment variables that some Git
|
# Ephemeral (per request) storage for environment variables that some
|
||||||
# commands need during internal API calls made from Git push hooks.
|
# 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
|
# See
|
||||||
# $GIT_OBJECT_DIRECTORY. Without it set, the new objects cannot be retrieved
|
# https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/object_quarantine.md#gitlab-and-git-object-quarantine
|
||||||
# (this would break push rules for instance).
|
# for more information.
|
||||||
#
|
#
|
||||||
# This class is thread-safe via RequestStore.
|
# This class is thread-safe via RequestStore.
|
||||||
class HookEnv
|
class HookEnv
|
||||||
|
|
|
||||||
|
|
@ -104,6 +104,20 @@ describe Gitlab::Ci::Parsers::Test::Junit do
|
||||||
'Some error'
|
'Some error'
|
||||||
end
|
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
|
context 'and has an unknown type' do
|
||||||
let(:testcase_content) { '<foo>Some foo</foo>' }
|
let(:testcase_content) { '<foo>Some foo</foo>' }
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue