Add latest changes from gitlab-org/gitlab@master

GITLAB_SHELL_VERSION

-11.0.0
+12.0.0

GITLAB_WORKHORSE_VERSION

-8.23.0
+8.24.0

doc/raketasks/backup_restore.md

@@ -115,7 +115,7 @@ also running Unicorn/Puma and/or Sidekiq.
 Example output:
-```
+```plaintext
 Dumping database tables:
 - Dumping table events... [DONE]
 - Dumping table issues... [DONE]
@@ -465,7 +465,7 @@ For installations from source:
 Note: This option only works for remote storage. If you want to group your backups
 you can pass a `DIRECTORY` environment variable:
-```
+```shell
 sudo gitlab-backup create DIRECTORY=daily
 sudo gitlab-backup create DIRECTORY=weekly
 ```
@@ -586,7 +586,7 @@ crontab -e
 There, add the following line to schedule the backup for everyday at 2 AM:
-```
+```plaintext
 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
 ```
@@ -614,7 +614,7 @@ sudo -u git crontab -e # Edit the crontab for the git user
 Add the following lines at the bottom:
-```
+```plaintext
 # Create a full backup of the GitLab repositories and SQL database every day at 4am
 0 4 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1
 ```
@@ -674,7 +674,7 @@ Read more on [configuring NFS mounts](../administration/high_availability/nfs.md
 ### Restore for installation from source
-```
+```shell
 # Stop processes that are connected to the database
 sudo service gitlab stop
@@ -683,7 +683,7 @@ bundle exec rake gitlab:backup:restore RAILS_ENV=production
 Example output:
-```
+```plaintext
 Unpacking backup... [DONE]
 Restoring database tables:
 -- create_table("events", {:force=>true})
@@ -853,7 +853,7 @@ will have all your repositories, but not any other data.
 If you are using backup restore procedures you might encounter the following warnings:
-```
+```plaintext
 psql:/var/opt/gitlab/backups/db/database.sql:22: ERROR:  must be owner of extension plpgsql
 psql:/var/opt/gitlab/backups/db/database.sql:2931: WARNING:  no privileges could be revoked for "public" (two occurrences)
 psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING:  no privileges were granted for "public" (two occurrences)
@@ -1003,7 +1003,7 @@ GitLab instance after restoring the registry data.
 These failures will mention permission issues in the registry logs, like:
-```
+```plaintext
 level=error
 msg="response completed with error"
 err.code=unknown

doc/raketasks/cleanup.md

@@ -6,7 +6,7 @@ Clean up local project upload files if they don't exist in GitLab database. The
 task attempts to fix the file if it can find its project, otherwise it moves the
 file to a lost and found directory.
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:project_uploads
@@ -16,8 +16,9 @@ bundle exec rake gitlab:cleanup:project_uploads RAILS_ENV=production
 Example output:
-```
+```shell
 $ sudo gitlab-rake gitlab:cleanup:project_uploads
+
 I, [2018-07-27T12:08:27.671559 #89817]  INFO -- : Looking for orphaned project uploads to clean up. Dry run...
 D, [2018-07-27T12:08:28.293568 #89817] DEBUG -- : Processing batch of 500 project upload file paths, starting with /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out
 I, [2018-07-27T12:08:28.689869 #89817]  INFO -- : Can move to lost and found /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out -> /opt/gitlab/embedded/service/gitlab-rails/public/uploads/-/project-lost-found/test.out
@@ -35,7 +36,7 @@ I, [2018-07-27T12:08:33.760257 #89817]  INFO -- : Did move to lost and found /op
 Remove object store upload files if they don't exist in GitLab database.
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:remote_upload_files
@@ -45,7 +46,7 @@ bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production
 Example output:
-```
+```shell
 $ sudo gitlab-rake gitlab:cleanup:remote_upload_files
 I, [2018-08-02T10:26:13.995978 #45011]  INFO -- : Looking for orphaned remote uploads to remove. Dry run...
@@ -54,7 +55,7 @@ I, [2018-08-02T10:26:14.120482 #45011]  INFO -- : Can be moved to lost and found
 I, [2018-08-02T10:26:14.120634 #45011]  INFO -- : To cleanup these files run this command with DRY_RUN=false
 ```
-```
+```shell
 $ sudo gitlab-rake gitlab:cleanup:remote_upload_files DRY_RUN=false
 I, [2018-08-02T10:26:47.598424 #45087]  INFO -- : Looking for orphaned remote uploads to remove...
@@ -109,7 +110,7 @@ level with `NICENESS`. Below are the valid levels, but consult
 ## Remove expired ActiveSession lookup keys
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys

doc/raketasks/features.md

@@ -15,6 +15,6 @@ Old path: `git@example.org:myrepo.git`
 New path: `git@example.org:username/myrepo.git` or `git@example.org:groupname/myrepo.git`
-```
+```shell
 bundle exec rake gitlab:enable_namespaces RAILS_ENV=production
 ```

doc/raketasks/generate_sample_prometheus_data.md

@@ -11,6 +11,6 @@ which loads the appropriate data set if it is present within the `sample_metrics
 **Example:**
-```
+```shell
 bundle exec rake gitlab:generate_sample_prometheus_data[21]
 ```

doc/raketasks/import.md

@@ -15,7 +15,7 @@
 The new folder needs to have Git user ownership and read/write/execute access for Git user and its group:
-```
+```shell
 sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
 ```
@@ -27,7 +27,7 @@ sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
 If we copy the repos to `/var/opt/gitlab/git-data/repository-import-<date>`, and repo A needs to be under the groups G1 and G2, it will
 have to be created under those folders: `/var/opt/gitlab/git-data/repository-import-<date>/G1/G2/A.git`.
-```
+```shell
 sudo cp -r /old/git/foo.git /var/opt/gitlab/git-data/repository-import-<date>/new_group/
 # Do this once when you are done copying git repositories
@@ -57,7 +57,7 @@ sudo -u git -H bundle exec rake gitlab:import:repos['/var/opt/gitlab/git-data/re
 #### Example output
-```
+```plaintext
 Processing /var/opt/gitlab/git-data/repository-import-1/a/b/c/blah.git
  * Using namespace: a/b/c
  * Created blah (a/b/c/blah)

doc/raketasks/list_repos.md

@@ -3,7 +3,7 @@
 You can print a list of all Git repositories on disk managed by
 GitLab with the following command:
-```
+```shell
 # Omnibus
 sudo gitlab-rake gitlab:list_repos
@@ -17,7 +17,7 @@ a date with the 'SINCE' environment variable. The time you specify
 is parsed by the Rails [TimeZone#parse
 function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).
-```
+```shell
 # Omnibus
 sudo gitlab-rake gitlab:list_repos SINCE='Sep 1 2015'

doc/raketasks/user_management.md

@@ -91,7 +91,7 @@ production:
 Next, generate a new secret:
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake secret
@@ -102,7 +102,7 @@ bundle exec rake secret RAILS_ENV=production
 Now you need to stop the GitLab server, back up the existing secrets file and
 update the database:
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-ctl stop
 sudo cp config/secrets.yml config/secrets.yml.bak
@@ -122,7 +122,7 @@ error.
 Finally, change `config/secrets.yml` to set `otp_key_base` to `<new key>` and
 restart. Again, make sure you're operating in the **production** section.
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-ctl start
@@ -133,7 +133,7 @@ sudo /etc/init.d/gitlab start
 If there are any problems (perhaps using the wrong value for `old_key`), you can
 restore your backup of `config/secrets.yml` and rollback the changes:
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-ctl stop
 sudo gitlab-rake gitlab:two_factor:rotate_key:rollback filename=backup.csv

doc/security/crime_vulnerability.md

@@ -33,7 +33,7 @@ Although SPDY is enabled in Omnibus installations, CRIME relies on compression
 The Nessus scanner, [reports a possible CRIME vulnerability][nessus] in GitLab
 similar to the following format:
-```
+```plaintext
 Description
 This remote service has one of two configurations that are known to be required for the CRIME attack:

doc/security/rack_attack.md

@@ -60,7 +60,7 @@ default['gitlab']['gitlab-rails']['rack_attack_protected_paths'] = [
 This header is included in responses to blocked requests:
-```
+```plaintext
 Retry-After: 60
 ```
@@ -109,7 +109,7 @@ No response headers are provided.
 1. Reconfigure GitLab:
-   ```
+   ```shell
    sudo gitlab-ctl reconfigure
    ```
@@ -202,7 +202,7 @@ the load balancer. In that case, you will need to:
 1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
 1. Reconfigure GitLab:
-   ```
+   ```shell
    sudo gitlab-ctl reconfigure
    ```

doc/ssh/README.md

@@ -124,7 +124,7 @@ To create a new SSH key pair:
    If, in any case, you want to add or change the password of your SSH key pair,
    you can use the `-p` flag:
-   ```
+   ```shell
    ssh-keygen -p -f <keyname>
    ```
@@ -206,7 +206,7 @@ authenticity of the GitLab host you are connecting to.
 For example, when connecting to GitLab.com, answer `yes` to add GitLab.com to
 the list of trusted hosts:
-```
+```plaintext
 The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
 ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
 Are you sure you want to continue connecting (yes/no)? yes
@@ -423,8 +423,9 @@ security risks.
 The GitLab check process includes a check for this condition, and will direct you
 to this section if your server is configured like this, e.g.:
-```
+```shell
 $ gitlab-rake gitlab:check
+
 # ...
 Git user has default SSH configuration? ... no
   Try fixing it:

doc/system_hooks/system_hooks.md

@@ -41,7 +41,7 @@ for Push and Tag events, but we never display commits.
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: System Hook
 ```
@@ -396,7 +396,7 @@ It generates one event per modified branch.
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: System Hook
 ```
@@ -462,7 +462,7 @@ It generates one event per modified tag.
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: System Hook
 ```
@@ -516,7 +516,7 @@ updated/merged/closed or a commit is added in the source branch.
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: System Hook
 ```
@@ -643,7 +643,7 @@ Triggered only once when you push to the repository (including tags).
 **Request header**:
-```
+```plaintext
 X-Gitlab-Event: System Hook
 ```

doc/update/mysql_to_postgresql.md

@@ -54,13 +54,13 @@ pgloader within the container as it is not included in the container image.
 1. Start a shell session in the context of the running container:
-   ``` bash
+   ```shell
    docker exec -it gitlab bash
    ```
 1. Install pgloader:
-   ``` bash
+   ```shell
    apt-get update
    apt-get -y install pgloader
    ```
@@ -78,7 +78,7 @@ need to enable the bundled PostgreSQL:
 1. Edit `/etc/gitlab/gitlab.rb` to enable bundled PostgreSQL:
-   ```
+   ```ruby
    postgresql['enable'] = true
    ```
@@ -116,7 +116,7 @@ new PostgreSQL one:
 1. Save the following snippet in a `commands.load` file, and edit with your
    MySQL database `username`, `password` and `host`:
-   ```
+   ```sql
    LOAD DATABASE
         FROM mysql://username:password@host/gitlabhq_production
         INTO postgresql://gitlab-psql@unix://var/opt/gitlab/postgresql:/gitlabhq_production
@@ -143,7 +143,7 @@ new PostgreSQL one:
 1. Once the migration finishes, you should see a summary table that looks like
    the following:
-   ```
+   ```plaintext
                                     table name       read   imported     errors      total time
    -----------------------------------------------  ---------  ---------  ---------  --------------
                                    fetch meta data        119        119          0          0.388s
@@ -217,7 +217,7 @@ new PostgreSQL one:
 1. Save the following snippet in a `commands.load` file, and edit with your
    MySQL `username`, `password` and `host`:
-   ```
+   ```sql
    LOAD DATABASE
         FROM mysql://username:password@host/gitlabhq_production
         INTO postgresql://postgres@unix://var/run/postgresql:/gitlabhq_production
@@ -244,7 +244,7 @@ new PostgreSQL one:
 1. Once the migration finishes, you should see a summary table that looks like
    the following:
-   ```
+   ```plaintext
                                     table name       read   imported     errors      total time
    -----------------------------------------------  ---------  ---------  ---------  --------------
                                    fetch meta data        119        119          0          0.388s
@@ -284,7 +284,7 @@ Sometimes, you might encounter some errors during or after the migration.
 The PostgreSQL user that you use for the migration MUST have **superuser** privileges.
 Otherwise, you may see a similar message to the following:
-```
+```plaintext
 debugger invoked on a CL-POSTGRES-ERROR:INSUFFICIENT-PRIVILEGE in thread
     #<THREAD "lparallel" RUNNING {10078A3513}>:
       Database error 42501: permission denied: "RI_ConstraintTrigger_a_20937" is a system trigger

doc/update/restore_after_failure.md

@@ -28,7 +28,7 @@ may need to manually correct the problem next time you upgrade.
 Example error:
-```
+```plaintext
 == 20151103134857 CreateLfsObjects: migrating =================================
 -- create_table(:lfs_objects)
 rake aborted!
@@ -48,7 +48,7 @@ need to do.
 Pass the version to a database rake task to manually mark the migration as
 complete.
-```
+```shell
 # Source install
 sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
@@ -62,7 +62,7 @@ migrations are marked complete.
 ### GitLab < 8.6
-```
+```shell
 # Source install
 sudo -u git -H bundle exec rails console -e production
@@ -72,7 +72,7 @@ sudo gitlab-rails console
 At the Rails console, type the following commands:
-```
+```ruby
 ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) VALUES('20151103134857')")
 exit
 ```

doc/user/analytics/value_stream_analytics.md

@@ -78,8 +78,8 @@ Each stage of Value Stream Analytics is further described in the table below.
 | Plan      | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
 | Code      | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
 | Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
-| Review    | Measures the median time taken to review the merge request that has closing issue pattern, between its creation and until it's merged. |
-| Staging   | Measures the median time between merging the merge request with closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
+| Review    | Measures the median time taken to review the merge request that has a closing issue pattern, between its creation and until it's merged. |
+| Staging   | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
 | Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**. |
 How this works, behind the scenes:

doc/user/profile/account/two_factor_authentication.md

@@ -39,7 +39,7 @@ To enable 2FA:
 1. **In GitLab:**
    1. Log in to your GitLab account.
-   1. Go to your **Profile Settings**.
+   1. Go to your [**Profile settings**](../index.md#profile-settings).
    1. Go to **Account**.
    1. Click **Enable Two-factor Authentication**.
 1. **On your device (usually your phone):**
@@ -84,7 +84,7 @@ Search for `security.webauth.u2f` and double click on it to toggle to `true`.
 To set up 2FA with a U2F device:
 1. Log in to your GitLab account.
-1. Go to your **Profile Settings**.
+1. Go to your [**Profile settings**](../index.md#profile-settings).
 1. Go to **Account**.
 1. Click **Enable Two-Factor Authentication**.
 1. Plug in your U2F device.
@@ -139,7 +139,7 @@ request and you will be automatically logged in.
 If you ever need to disable 2FA:
 1. Log in to your GitLab account.
-1. Go to your **Profile Settings**.
+1. Go to your [**Profile settings**](../index.md#profile-settings).
 1. Go to **Account**.
 1. Click **Disable**, under **Two-Factor Authentication**.
@@ -226,7 +226,7 @@ To regenerate 2FA recovery codes, you need access to a desktop browser:
 1. Navigate to GitLab.
 1. Sign in to your GitLab account.
-1. Go to your [Profile settings](../index.md#profile-settings).
+1. Go to your [**Profile settings**](../index.md#profile-settings).
 1. Select **{account}** **Account > Two-Factor Authentication (2FA)**.
 1. If you've already configured 2FA, click **Manage two-factor authentication**.
 1. In the **Register Two-Factor Authenticator** pane, click **Regenerate recovery codes**.

doc/user/project/issues/index.md

@@ -6,9 +6,14 @@ Issues are the fundamental medium for collaborating on ideas and planning work i
 The GitLab issue tracker is an advanced tool for collaboratively developing ideas, solving problems, and planning work.
-Issues can allow you and your team to share and discuss proposals
-before, and during, their implementation. However, they can be used for a variety of
-other purposes, customized to your needs and workflow.
+Issues can allow sharing and discussion of proposals before, and during,
+their implementation between:
+
+- You and your team.
+- Outside collaborators.
+
+They can also be used for a variety of other purposes, customized to your
+needs and workflow.
 Issues are always associated with a specific project, but if you have multiple projects in a group,
 you can also view all the issues collectively at the group level.

doc/user/project/pipelines/schedules.md

@@ -116,12 +116,17 @@ The next time a pipeline is scheduled, your credentials will be used.
 ![Schedules list](img/pipeline_schedules_ownership.png)
-NOTE: **Note:**
-If the owner of a pipeline schedule doesn't have the ability to create pipelines
-on the target branch, the schedule will stop creating new pipelines. This can
-happen if the owner is blocked or removed from the project, or
-the target branch or tag is protected. In this case, someone with sufficient
-privileges must take ownership of the schedule.
+If the owner of a pipeline schedule doesn't have the ability to create
+pipelines on the target branch, the schedule will stop creating new
+pipelines.
+
+This can happen if, for example:
+
+- The owner is blocked or removed from the project.
+- The target branch or tag is protected.
+
+In this case, someone with sufficient privileges must take ownership of the
+schedule.
 <!-- ## Troubleshooting