Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/notes/stores/mutations.js

@@ -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) {

changelogs/unreleased/parse-skipped-specs-from-junit-reports.yml

@@ -0,0 +1,5 @@
+---
+title: Detect skipped specs in JUnit reports and set TestCase status
+merge_request: 28053
+author:
+type: fixed

doc/development/api_graphql_styleguide.md

@@ -798,11 +798,15 @@ that wraps around a query being executed. It is implemented as a module that use
 Example: `Present`
 
 ```ruby
+module Gitlab
+  module Graphql
     module Present
       #... some code above...
 
       def self.use(schema_definition)
-    schema_definition.instrument(:field, Instrumentation.new)
+        schema_definition.instrument(:field, ::Gitlab::Graphql::Present::Instrumentation.new)
+      end
+    end
   end
 end
 ```

doc/development/distributed_tracing.md

@@ -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

lib/gitlab/ci/parsers/test/junit.rb

@@ -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

lib/gitlab/git/hook_env.rb

@@ -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

spec/lib/gitlab/ci/parsers/test/junit_spec.rb

@@ -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>' }