Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/labels_select.js

@@ -32,6 +32,7 @@ export default class LabelsSelect {
         $selectbox,
         $sidebarCollapsedValue,
         $value,
+        $dropdownMenu,
         abilityName,
         defaultLabel,
         issueUpdateURL,
@@ -67,6 +68,7 @@ export default class LabelsSelect {
       $sidebarCollapsedValue = $block.find('.sidebar-collapsed-icon span');
       $sidebarLabelTooltip = $block.find('.js-sidebar-labels-tooltip');
       $value = $block.find('.value');
+      $dropdownMenu = $dropdown.parent().find('.dropdown-menu');
       $loading = $block.find('.block-loading').fadeOut();
       fieldName = $dropdown.data('fieldName');
       initialSelected = $selectbox
@@ -454,9 +456,21 @@ export default class LabelsSelect {
             }
             $loading.fadeIn();
+            const oldLabels = boardsStore.detail.issue.labels;
             boardsStore.detail.issue
               .update($dropdown.attr('data-issue-update'))
+              .then(() => {
+                if (isScopedLabel(label)) {
+                  const prevIds = oldLabels.map(label => label.id);
+                  const newIds = boardsStore.detail.issue.labels.map(label => label.id);
+                  const differentIds = _.difference(prevIds, newIds);
+                  $dropdown.data('marked', newIds);
+                  $dropdownMenu
+                    .find(differentIds.map(id => `[data-label-id="${id}"]`).join(','))
+                    .removeClass('is-active');
+                }
+              })
               .then(fadeOutLoader)
               .catch(fadeOutLoader);
           } else if (handleClick) {

doc/api/project_snippets.md

@@ -78,7 +78,7 @@ Parameters:
 - `title` (required) - The title of a snippet
 - `file_name` (required) - The name of a snippet file
 - `description` (optional) - The description of a snippet
-- `code` (required) - The content of a snippet
+- `content` (required) - The content of a snippet
 - `visibility` (required) - The snippet's visibility
 Example request:
@@ -97,7 +97,7 @@ curl --request POST https://gitlab.com/api/v4/projects/:id/snippets \
   "title" : "Example Snippet Title",
   "description" : "More verbose snippet description",
   "file_name" : "example.txt",
-  "code" : "source code \n with multiple lines\n",
+  "content" : "source code \n with multiple lines\n",
   "visibility" : "private"
 }
 ```
@@ -117,7 +117,7 @@ Parameters:
 - `title` (optional) - The title of a snippet
 - `file_name` (optional) - The name of a snippet file
 - `description` (optional) - The description of a snippet
-- `code` (optional) - The content of a snippet
+- `content` (optional) - The content of a snippet
 - `visibility` (optional) - The snippet's visibility
 Example request:
@@ -136,7 +136,7 @@ curl --request PUT https://gitlab.com/api/v4/projects/:id/snippets \
   "title" : "Updated Snippet Title",
   "description" : "More verbose snippet description",
   "file_name" : "new_filename.txt",
-  "code" : "updated source code \n with multiple lines\n",
+  "content" : "updated source code \n with multiple lines\n",
   "visibility" : "private"
 }
 ```

doc/ci/caching/index.md

@@ -491,8 +491,8 @@ job B:
 To fix that, use different `keys` for each job.
 In another case, let's assume you have more than one Runners assigned to your
-project, but the distributed cache is not enabled. We want the second time the
-pipeline is run, `job A` and `job B` to re-use their cache (which in this case
+project, but the distributed cache is not enabled. The second time the
+pipeline is run, we want `job A` and `job B` to re-use their cache (which in this case
 will be different):
 ```yaml
@@ -518,7 +518,7 @@ job B:
 ```
 In that case, even if the `key` is different (no fear of overwriting), you
-might experience the cached files to "get cleaned" before each stage if the
+might experience that the cached files "get cleaned" before each stage if the
 jobs run on different Runners in the subsequent pipelines.
 ## Clearing the cache

doc/ci/merge_request_pipelines/index.md

@@ -151,13 +151,13 @@ parent project. This means you cannot completely trust the pipeline result,
 because, technically, external contributors can disguise their pipeline results
 by tweaking their GitLab Runner in the forked project.
-There are multiple reasons about why GitLab doesn't allow those pipelines to be
+There are multiple reasons why GitLab doesn't allow those pipelines to be
 created in the parent project, but one of the biggest reasons is security concern.
 External users could steal secret variables from the parent project by modifying
 `.gitlab-ci.yml`, which could be some sort of credentials. This should not happen.
 We're discussing a secure solution of running pipelines for merge requests
-that submitted from forked projects,
+that are submitted from forked projects,
 see [the issue about the permission extension](https://gitlab.com/gitlab-org/gitlab-foss/issues/23902).
 ## Additional predefined variables

doc/ci/review_apps/index.md

@@ -24,8 +24,8 @@ In the above example:
 - A Review App is built every time a commit is pushed to `topic branch`.
 - The reviewer fails two reviews before passing the third review.
-- Once the review as passed, `topic branch` is merged into `master` where it's deploy to staging.
-- After been approved in staging, the changes that were merged into `master` are deployed in to production.
+- Once the review has passed, `topic branch` is merged into `master` where it is deployed to staging.
+- After having been approved in staging, the changes that were merged into `master` are deployed in to production.
 ## How Review Apps work

doc/ci/triggers/README.md

@@ -157,7 +157,7 @@ curl --request POST \
 You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
 you have two projects, A and B, and you want to trigger a rebuild on the `master`
 branch of project B whenever a tag on project A is created. This is the job you
-need to add in project's A `.gitlab-ci.yml`:
+need to add in project A's `.gitlab-ci.yml`:
 ```yaml
 build_docs:

doc/topics/autodevops/index.md

@@ -98,7 +98,7 @@ To make full use of Auto DevOps, you will need:
 - **GitLab Runner** (for all stages)
   Your Runner needs to be configured to be able to run Docker. Generally this
-  means using the either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
+  means using either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
   or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with
   [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
@@ -1169,13 +1169,13 @@ This configuration is deprecated and will be removed in the future.
 TIP: **Tip:**
 You can also set this inside your [project's settings](#deployment-strategy).
-This configuration based on
+This configuration is based on
 [incremental rollout to production](#incremental-rollout-to-production-premium).
 Everything behaves the same way, except:
 - It's enabled by setting the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
-- Instead of the standard `production` job, the following jobs with a 5 minute delay between each are created:
+- Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each :
   1. `timed rollout 10%`
   1. `timed rollout 25%`
   1. `timed rollout 50%`

doc/user/admin_area/settings/continuous_integration.md

@@ -54,6 +54,9 @@ To change it at the:
   1. Change the value of **maximum artifacts size (in MB)**.
   1. Press **Save changes** for the changes to take effect.
+NOTE: **Note**
+The setting at all levels is only available to GitLab administrators.
+
 ## Default artifacts expiration **(CORE ONLY)**
 The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)

doc/user/project/labels.md

@@ -2,9 +2,9 @@
 ## Overview
-Labels allow you to categorize issues or merge requests using descriptive titles like
+Labels allow you to categorize epics, issues, and merge requests using descriptive titles like
 `bug`, `feature request`, or `docs`. Each label also has a customizable color. They
-allow you to quickly and dynamically filter and manage issues or merge requests you
+allow you to quickly and dynamically filter and manage epics, issues and merge requests you
 care about, and are visible throughout GitLab in most places where issues and merge
 requests are located.
@@ -12,8 +12,8 @@ requests are located.
 In GitLab, you can create project and group labels:
-- **Project labels** can be assigned to issues or merge requests in that project only.
-- **Group labels** can be assigned to any issue or merge request in any project in
+- **Project labels** can be assigned to epics, issues and merge requests in that project only.
+- **Group labels** can be assigned to any epics, issue and merge request in any project in
   that group, or any subgroups of the group.
 ## Scoped labels **(PREMIUM)**
@@ -21,7 +21,7 @@ In GitLab, you can create project and group labels:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9175) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 Scoped labels allow teams to use the simple and familiar label feature to
-annotate their issues, merge requests, and epics to achieve custom fields and
+annotate their epics, issues, merge requests, and epics to achieve custom fields and
 custom workflow states by leveraging a special label title syntax.
 A scoped label is a kind of label defined by a special double-colon syntax
@@ -141,11 +141,8 @@ action cannot be reversed and the changes are permanent.
 ## Assigning labels from the sidebar
-Every issue and merge request can be assigned any number of labels. The labels are
-visible on every issue and merge request page, in the sidebar. They are also visible on:
-
-- Every issue and merge request page in the sidebar.
-- The issue board.
+Every epic, issue, and merge request can be assigned any number of labels. The labels are
+visible on every epic, issue and merge request page, in the sidebar and on your issue boards.
 From the sidebar, you can assign or unassign a label to the object (i.e. label or
 unlabel it). You can also perform this as a [quick action](quick_actions.md),
@@ -166,11 +163,11 @@ GitLab will check both the label titles and descriptions for the search.
 ## Filtering by label
-The following can be filtered labels:
+The following can be filtered by labels:
+- Epic lists **(ULTIMATE)**
 - Issue lists
 - Merge Request lists
-- Epic lists **(ULTIMATE)**
 - Issue Boards
 ### Filtering in list pages
@@ -180,7 +177,7 @@ The following can be filtered labels:
   - Group labels (including subgroup ancestors)
   - Project labels
-- From the group issue list page and the group merge request list page, you can
+- From the group epic lists page, issue list page and the group merge request list page, you can
   [filter](../search/index.md#issues-and-merge-requests) by:
   - Group labels (including subgroup ancestors and subgroup descendants)
   - Project labels
@@ -214,7 +211,7 @@ The following can be filtered labels:
 From the project label list page and the group label list page, you can subscribe
 to [notifications](../../workflow/notifications.md) of a given label, to alert you
-that the label has been assigned to an issue or merge request.
+that the label has been assigned to an epic, issue, and merge request.
 ![Labels subscriptions](img/labels_subscriptions_v12_1.png)
@@ -226,7 +223,7 @@ that the label has been assigned to an issue or merge request.
 > - Priority sorting is based on the highest priority label only. [This discussion](https://gitlab.com/gitlab-org/gitlab-foss/issues/18554) considers changing this.
 Labels can have relative priorities, which are used in the "Label priority" and
-"Priority" sort orders of the issue and merge request list pages.
+"Priority" sort orders of the epic, issue, and merge request list pages.
 From the project label list page, star a label to indicate that it has a priority.
@@ -242,8 +239,8 @@ on the project label list page.
 ![Drag to change label priority](img/labels_drag_priority_v12_1.gif)
-On the merge request and issue pages, for both groups and projects, you can sort by `Label priority`
-and `Priority`, which account for objects (issues and merge requests) that have prioritized
+On the epic, merge request and issue pages, for both groups and projects, you can sort by `Label priority`
+and `Priority`, which account for objects (epic, issues, and merge requests) that have prioritized
 labels assigned to them.
 If you sort by `Label priority`, GitLab considers this sort comparison order:

doc/user/project/pipelines/job_artifacts.md

@@ -50,14 +50,9 @@ For more examples on artifacts, follow the [artifacts reference in
 ## Browsing artifacts
-> With GitLab 9.2, PDFs, images, videos and other formats can be previewed
-> directly in the job artifacts browser without the need to download them.
-> With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
-> directly in a new tab without the need to download them when
-> [GitLab Pages](../../../administration/pages/index.md) is enabled.
-> The same holds for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
-> With [GitLab 12.4][gitlab-16675], also artifacts in private projects can be previewed
-> when [GitLab Pages access control](../../../administration/pages/index.md#access-control) is enabled.
+> - From GitLab 9.2, PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them.
+> - Introduced in [GitLab 10.1][ce-14399], HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
+> - Introduced in [GitLab 12.4][gitlab-16675], artifacts in private projects can be previewed when [GitLab Pages access control](../../../administration/pages/index.md#access-control) is enabled.
 After a job finishes, if you visit the job's specific page, there are three
 buttons. You can download the artifacts archive or browse its contents, whereas
@@ -70,7 +65,7 @@ The archive browser shows the name and the actual file size of each file in the
 archive. If your artifacts contained directories, then you are also able to
 browse inside them.
-Below you can see how browsing looks like. In this case we have browsed inside
+Below you can see what browsing looks like. In this case we have browsed inside
 the archive and at this point there is one directory, a couple files, and
 one HTML file that you can view directly online when
 [GitLab Pages](../../../administration/pages/index.md) is enabled (opens in a new tab).

lib/gitlab/metrics/system.rb

@@ -63,6 +63,19 @@ module Gitlab
       def self.monotonic_time
         Process.clock_gettime(Process::CLOCK_MONOTONIC, :float_second)
       end
+
+      def self.thread_cpu_time
+        return unless defined?(Process::CLOCK_THREAD_CPUTIME_ID)
+
+        Process.clock_gettime(Process::CLOCK_THREAD_CPUTIME_ID, :float_second)
+      end
+
+      def self.thread_cpu_duration(start_time)
+        end_time = thread_cpu_time
+        return unless start_time && end_time
+
+        end_time - start_time
+      end
     end
   end
 end

lib/gitlab/metrics/transaction.rb

@@ -44,6 +44,10 @@ module Gitlab
         duration.in_milliseconds.to_i
       end
+      def thread_cpu_duration
+        System.thread_cpu_duration(@thread_cputime_start)
+      end
+
       def allocated_memory
         @memory_after - @memory_before
       end
@@ -53,12 +57,14 @@ module Gitlab
         @memory_before = System.memory_usage
         @started_at = System.monotonic_time
+        @thread_cputime_start = System.thread_cpu_time
         yield
       ensure
         @memory_after = System.memory_usage
         @finished_at = System.monotonic_time
+        self.class.gitlab_transaction_cputime_seconds.observe(labels, thread_cpu_duration)
         self.class.gitlab_transaction_duration_seconds.observe(labels, duration)
         self.class.gitlab_transaction_allocated_memory_bytes.observe(labels, allocated_memory * 1024.0)
@@ -142,6 +148,12 @@ module Gitlab
         "#{labels[:controller]}##{labels[:action]}" if labels && !labels.empty?
       end
+      define_histogram :gitlab_transaction_cputime_seconds do
+        docstring 'Transaction thread cputime'
+        base_labels BASE_LABELS
+        buckets [0.1, 0.25, 0.5, 1.0, 2.5, 5.0]
+      end
+
       define_histogram :gitlab_transaction_duration_seconds do
         docstring 'Transaction duration'
         base_labels BASE_LABELS

spec/features/boards/sidebar_spec.rb

@@ -14,6 +14,8 @@ describe 'Issue Boards', :js do
   let!(:bug)         { create(:label, project: project, name: 'Bug') }
   let!(:regression)  { create(:label, project: project, name: 'Regression') }
   let!(:stretch)     { create(:label, project: project, name: 'Stretch') }
+  let!(:scoped_label_1)     { create(:label, project: project, name: 'Scoped::Label1') }
+  let!(:scoped_label_2)     { create(:label, project: project, name: 'Scoped::Label2') }
   let!(:issue1)      { create(:labeled_issue, project: project, assignees: [user], milestone: milestone, labels: [development], relative_position: 2) }
   let!(:issue2)      { create(:labeled_issue, project: project, labels: [development, stretch], relative_position: 1) }
   let(:board)        { create(:board, project: project) }
@@ -27,6 +29,8 @@ describe 'Issue Boards', :js do
   end
   before do
+    stub_licensed_features(scoped_labels: true)
+
     project.add_maintainer(user)
     sign_in(user)
@@ -309,6 +313,33 @@ describe 'Issue Boards', :js do
       expect(card).to have_content(bug.title)
     end
+    it 'removes existing scoped label' do
+      click_card(card)
+
+      page.within('.labels') do
+        click_link 'Edit'
+
+        wait_for_requests
+
+        click_link scoped_label_1.title
+        click_link scoped_label_2.title
+
+        wait_for_requests
+
+        find('.dropdown-menu-close-icon').click
+
+        page.within('.value') do
+          expect(page).to have_selector('.scoped-label-wrapper', count: 1)
+          expect(page).not_to have_content(scoped_label_1.title)
+          expect(page).to have_content(scoped_label_2.title)
+        end
+      end
+
+      expect(card).to have_selector('.scoped-label-wrapper', count: 1)
+      expect(card).not_to have_content(scoped_label_1.title)
+      expect(card).to have_content(scoped_label_2.title)
+    end
+
     it 'adds a multiple labels' do
       click_card(card)

spec/lib/gitlab/metrics/transaction_spec.rb

@@ -27,6 +27,14 @@ describe Gitlab::Metrics::Transaction do
     end
   end
+  describe '#thread_cpu_duration' do
+    it 'returns the duration of a transaction in seconds' do
+      transaction.run { }
+
+      expect(transaction.thread_cpu_duration).to be > 0
+    end
+  end
+
   describe '#allocated_memory' do
     it 'returns the allocated memory in bytes' do
       transaction.run { 'a' * 32 }