Add latest changes from gitlab-org/gitlab@master

changelogs/unreleased/sh-add-weight-simple-sort.yml

+---
+title: Optimize issue search when sorting by weight
+merge_request: 24208
+author:
+type: performance

config/initializers/console_message.rb

 # rubocop:disable Rails/Output
-if defined?(Rails::Console)
+if Gitlab::Runtime.console?
   # note that this will not print out when using `spring`
   justify = 15
   puts '-' * 80
-  puts " GitLab:".ljust(justify) + "#{Gitlab::VERSION} (#{Gitlab.revision})"
+  puts " GitLab:".ljust(justify) + "#{Gitlab::VERSION} (#{Gitlab.revision}) #{Gitlab.ee? ? 'EE' : 'FOSS'}"
   puts " GitLab Shell:".ljust(justify) + "#{Gitlab::VersionInfo.parse(Gitlab::Shell.new.version)}"
   if Gitlab::Database.exists?

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -84,6 +84,13 @@ The following metrics are available:
 | `failed_login_captcha_total`                                   | Gauge     |                   11.0 | Counter of failed CAPTCHA attempts during login                                                     |                                                     |
 | `successful_login_captcha_total`                               | Gauge     |                   11.0 | Counter of successful CAPTCHA attempts during login                                                 |                                                     |
 | `auto_devops_pipelines_completed_total`                        | Counter   |                   12.7 | Counter of completed Auto DevOps pipelines, labeled by status                                       |                                                     |
+| `sidekiq_jobs_cpu_seconds`                                     | Histogram |                   12.4 | Seconds of cpu time to run Sidekiq job                                                              |                                                     |
+| `sidekiq_jobs_completion_seconds`                              | Histogram |                   12.2 | Seconds to complete Sidekiq job                                                                     |                                                     |
+| `sidekiq_jobs_queue_duration_seconds`                          | Histogram |                   12.5 | Duration in seconds that a Sidekiq job was queued before being executed                             |                                                     |
+| `sidekiq_jobs_failed_total`                                    | Counter   |                   12.2 | Sidekiq jobs failed                                                                                 |                                                     |
+| `sidekiq_jobs_retried_total`                                   | Counter   |                   12.2 | Sidekiq jobs retried                                                                                |                                                     |
+| `sidekiq_running_jobs`                                         | Gauge     |                   12.2 | Number of Sidekiq jobs running                                                                      |                                                     |
+| `sidekiq_concurrency`                                          | Gauge     |                   12.5 | Maximum number of Sidekiq jobs                                                                      |                                                     |
 ## Metrics controlled by a feature flag

doc/administration/operations/filesystem_benchmarking.md

@@ -37,7 +37,7 @@ completes.
 The output will vary depending on what version of `fio` installed. The following
 is an example output from `fio` v2.2.10 on a networked solid-state drive (SSD):
-```
+```plaintext
 test: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=64
     fio-2.2.10
     Starting 1 process

doc/administration/operations/moving_repositories.md

@@ -21,7 +21,7 @@ overhead and tar is almost always already installed on your system.
 However, it is not possible to resume an interrupted tar pipe:  if
 that happens then all data must be copied again.
-```
+```shell
 sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
   tar -C /mnt/gitlab/repositories -xf -'
 ```
@@ -34,7 +34,7 @@ You can also use a tar pipe to copy data to another server. If your
 `git` user has SSH access to the newserver as `git@newserver`, you
 can pipe the data through SSH.
-```
+```shell
 sudo -u git sh -c 'tar -C /var/opt/gitlab/git-data/repositories -cf - -- . |\
   ssh git@newserver tar -C /mnt/gitlab/repositories -xf -'
 ```
@@ -50,7 +50,7 @@ with tar. In this scenario it is better to use rsync. This utility
 is either already installed on your system or easily installable
 via apt, yum etc.
-```
+```shell
 sudo -u git  sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
   /mnt/gitlab/repositories'
 ```
@@ -64,7 +64,7 @@ If you want to see progress, replace `-a` with `-av`.
 If the `git` user on your source system has SSH access to the target
 server you can send the repositories over the network with rsync.
-```
+```shell
 sudo -u git sh -c 'rsync -a --delete /var/opt/gitlab/git-data/repositories/. \
   git@newserver:/mnt/gitlab/repositories'
 ```
@@ -99,7 +99,7 @@ First we create a new directory, owned by `git`, to hold transfer
 logs. We assume the directory is empty before we start the transfer
 procedure, and that we are the only ones writing files in it.
-```
+```shell
 # Omnibus
 sudo mkdir /var/opt/gitlab/transfer-logs
 sudo chown git:git /var/opt/gitlab/transfer-logs
@@ -110,7 +110,7 @@ sudo -u git -H mkdir /home/git/transfer-logs
 We seed the process with a list of the directories we want to copy.
-```
+```shell
 # Omnibus
 sudo -u git sh -c 'gitlab-rake gitlab:list_repos > /var/opt/gitlab/transfer-logs/all-repos-$(date +%s).txt'
@@ -124,7 +124,7 @@ the number of jobs done by GNU Parallel should converge to zero. If it
 does not, some repositories listed in `all-repos-1234.txt` may have been
 deleted/renamed before they could be copied.
-```
+```shell
 # Omnibus
 sudo -u git sh -c '
 cat /var/opt/gitlab/transfer-logs/* | sort | uniq -u |\
@@ -154,7 +154,7 @@ Then you might only want to sync repositories that were changed via GitLab
 _after_ that time. You can use the `SINCE` variable to tell `rake
 gitlab:list_repos` to only print repositories with recent activity.
-```
+```shell
 # Omnibus
 sudo gitlab-rake gitlab:list_repos SINCE='2015-10-1 12:00 UTC' |\
   sudo -u git \

doc/administration/operations/ssh_certificates.md

@@ -54,8 +54,9 @@ The SSH certificates being issued by that CA **MUST** have a "key id"
 corresponding to that user's username on GitLab, e.g. (some output
 omitted for brevity):
-```
+```shell
 $ ssh-add -L | grep cert | ssh-keygen -L -f -
+
 (stdin):1:
         Type: ssh-rsa-cert-v01@openssh.com user certificate
         Public key: RSA-CERT SHA256:[...]

doc/administration/operations/unicorn.md

@@ -29,7 +29,7 @@ requests.
 This is what a Unicorn worker timeout looks like in `unicorn_stderr.log`. The
 master process has PID 56227 below.
-```
+```plaintext
 [2015-06-05T10:58:08.660325 #56227] ERROR -- : worker=10 PID:53009 timeout (61s > 60s), killing
 [2015-06-05T10:58:08.699360 #56227] ERROR -- : reaped #<Process::Status: pid 53009 SIGKILL (signal 9)> worker=10
 [2015-06-05T10:58:08.708141 #62538]  INFO -- : worker=10 spawned pid=62538
@@ -79,7 +79,7 @@ threshold is a random value between 200 and 250 MB.  The master process (PID
 117565) then reaps the worker process and spawns a new 'worker 4' with PID
 127549.
-```
+```plaintext
 [2015-06-05T12:07:41.828374 #125918]  WARN -- : #<Unicorn::HttpServer:0x00000002734770>: worker (pid: 125918) exceeds memory limit (256413696 bytes > 254802235 bytes)
 [2015-06-05T12:07:41.828472 #125918]  WARN -- : Unicorn::WorkerKiller send SIGQUIT (pid: 125918) alive: 23 sec (trial 1)
 [2015-06-05T12:07:42.025916 #117565]  INFO -- : reaped #<Process::Status: pid 125918 exit 0> worker=4

doc/user/group/index.md

@@ -193,6 +193,25 @@ To change this setting for a specific group:
 To change this setting globally, see [Default project creation protection](../admin_area/settings/visibility_and_access_controls.md#default-project-creation-protection).
+## Viewing group activity
+
+A group's **Activity** page displays the most recent actions taken in a group, including:
+
+- **Push events**: Recent pushes to branches
+- **Merge events**: Recent merges
+- **Issue events**: Issues opened or closed
+- **Epic events**: Epics opened or closed
+- **Comments**: Comments opened or closed
+- **Team**: Team members who have joined or left the group
+
+The entire activity feed is also available in Atom format by clicking the
+**RSS** icon.
+
+To view a group's **Activity** page:
+
+1. Go to the group's page.
+1. In the left navigation menu, go to **Group Overview** and select **Activity**.
+
 ## Transfer projects into groups
 Learn how to [transfer a project into a group](../project/settings/index.md#transferring-an-existing-project-into-another-namespace).

doc/user/project/import/svn.md

@@ -43,14 +43,14 @@ installations from source, the default repository directory will be
 `/home/git/repositories/USER/REPO.git`. For convenience, assign this path to a
 variable:
-```
+```shell
 GIT_REPO_PATH=/var/opt/gitlab/git-data/repositories/USER/REPOS.git
 ```
 SubGit will keep this repository in sync with a remote SVN project. For
 convenience, assign your remote SVN project URL to a variable:
-```
+```shell
 SVN_PROJECT_URL=http://svn.company.com/repos/project
 ```
@@ -58,14 +58,14 @@ Next you need to run SubGit to set up a Git/SVN mirror. Make sure the following
 `subgit` command is ran on behalf of the same user that keeps ownership of
 GitLab Git repositories (by default `git`):
-```
+```shell
 subgit configure --layout auto $SVN_PROJECT_URL $GIT_REPO_PATH
 ```
 Adjust authors and branches mappings, if necessary. Open with your favorite
 text editor:
-```
+```shell
 edit $GIT_REPO_PATH/subgit/authors.txt
 edit $GIT_REPO_PATH/subgit/config
 ```
@@ -78,7 +78,7 @@ For more information regarding the SubGit configuration options, refer to
 Now that SubGit has configured the Git/SVN repos, run `subgit` to perform the
 initial translation of existing SVN revisions into the Git repository:
-```
+```shell
 subgit install $GIT_REPO_PATH
 ```
@@ -90,7 +90,7 @@ works transparently and does not require any special commands.
 If you would prefer to perform one-time cut over migration with `subgit`, use
 the `import` command instead of `install`:
-```
+```shell
 subgit import $GIT_REPO_PATH
 ```
@@ -145,7 +145,7 @@ svn log --quiet | grep -E "r[0-9]+ \| .+ \|" | cut -d'|' -f2 | sed 's/ //g' | so
 Use the output from the last command to construct the authors file.
 Create a file called `authors.txt` and add one mapping per line.
-```
+```plaintext
 janedoe = Jane Doe <janedoe@example.com>
 johndoe = John Doe <johndoe@example.com>
 ```

doc/user/project/integrations/webhooks.md

@@ -126,7 +126,7 @@ Also, if a single push includes changes for more than three (by default, dependi
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Push Hook
 ```
@@ -213,7 +213,7 @@ If a single push includes changes for more than three (by default, depending on
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Tag Push Hook
 ```
@@ -267,7 +267,7 @@ Triggered when a new issue is created or an existing issue was updated/closed/re
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Issue Hook
 ```
@@ -402,7 +402,7 @@ Valid target types:
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Note Hook
 ```
@@ -482,7 +482,7 @@ X-Gitlab-Event: Note Hook
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Note Hook
 ```
@@ -609,7 +609,7 @@ X-Gitlab-Event: Note Hook
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Note Hook
 ```
@@ -714,7 +714,7 @@ X-Gitlab-Event: Note Hook
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Note Hook
 ```
@@ -790,7 +790,7 @@ Triggered when a new merge request is created, an existing merge request was upd
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: Merge Request Hook
 ```
@@ -951,7 +951,7 @@ Triggered when a wiki page is created, updated or deleted.
 **Request Header**:
-```
+```plaintext
 X-Gitlab-Event: Wiki Page Hook
 ```
@@ -1007,7 +1007,7 @@ Triggered on status change of Pipeline.
 **Request Header**:
-```
+```plaintext
 X-Gitlab-Event: Pipeline Hook
 ```
@@ -1215,7 +1215,7 @@ Triggered on status change of a job.
 **Request Header**:
-```
+```plaintext
 X-Gitlab-Event: Job Hook
 ```
@@ -1328,7 +1328,7 @@ If the endpoint doesn't send its HTTP response within those 10 seconds, GitLab m
 If you are receiving multiple requests, you can try increasing the default value to wait for the HTTP response after sending the webhook
 by uncommenting or adding the following setting to your `/etc/gitlab/gitlab.rb`:
-```
+```ruby
 gitlab_rails['webhook_timeout'] = 10
 ```
@@ -1370,7 +1370,7 @@ Pick an unused port (e.g. 8000) and start the script: `ruby print_http_body.rb
 When you press 'Test' in GitLab, you should see something like this in the
 console:
-```
+```plaintext
 {"before":"077a85dd266e6f3573ef7e9ef8ce3343ad659c4e","after":"95cd4a99e93bc4bbabacfa2cd10e6725b1403c60",<SNIP>}
 example.com - - [14/May/2014:07:45:26 EDT] "POST / HTTP/1.1" 200 0
 - -> /

doc/user/project/issues/managing_issues.md

@@ -198,7 +198,7 @@ source code that can match references to:
 For example the following commit message:
-```
+```plaintext
 Awesome commit message
 Fix #20, Fixes #21 and Closes group/otherproject#22.

doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md

@@ -200,7 +200,7 @@ project is a fork (even a private fork) of the target project.
 Add the following alias to your `~/.gitconfig`:
-```
+```plaintext
 [alias]
     mr = !sh -c 'git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2' -
 ```
@@ -209,7 +209,7 @@ Now you can check out a particular merge request from any repository and any
 remote. For example, to check out the merge request with ID 5 as shown in GitLab
 from the `origin` remote, do:
-```
+```shell
 git mr origin 5
 ```
@@ -221,7 +221,7 @@ it out.
 Locate the section for your GitLab remote in the `.git/config` file. It looks
 like this:
-```
+```plaintext
 [remote "origin"]
   url = https://gitlab.com/gitlab-org/gitlab-foss.git
   fetch = +refs/heads/*:refs/remotes/origin/*
@@ -229,19 +229,19 @@ like this:
 You can open the file with:
-```
+```shell
 git config -e
 ```
 Now add the following line to the above section:
-```
+```plaintext
 fetch = +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*
 ```
 In the end, it should look like this:
-```
+```plaintext
 [remote "origin"]
   url = https://gitlab.com/gitlab-org/gitlab-foss.git
   fetch = +refs/heads/*:refs/remotes/origin/*
@@ -250,7 +250,7 @@ In the end, it should look like this:
 Now you can fetch all the merge requests:
-```
+```shell
 git fetch origin
 ...
@@ -262,7 +262,7 @@ From https://gitlab.com/gitlab-org/gitlab-foss.git
 And to check out a particular merge request:
-```
+```shell
 git checkout origin/merge-requests/1
 ```

doc/user/project/pages/custom_domains_ssl_tls_certification/index.md

@@ -174,13 +174,13 @@ from the GitLab project.
 To manually verify that you have properly configured the domain verification
 `TXT` DNS entry, you can run the following command in your terminal:
-```
+```shell
 dig _gitlab-pages-verification-code.<YOUR-PAGES-DOMAIN> TXT
 ```
 Expect the output:
-```
+```plaintext
 ;; ANSWER SECTION:
 _gitlab-pages-verification-code.<YOUR-PAGES-DOMAIN>. 300 IN TXT "gitlab-pages-verification-code=<YOUR-VERIFICATION-CODE>"
 ```