Merge remote-tracking branch 'origin/master' into...

Merge remote-tracking branch 'origin/master' into camilstaps/gitlab-ce-new-66023-public-private-fork-counts

doc/development/performance.md

@@ -123,7 +123,7 @@ Keeping that in mind, to create a profile, identify (or create) a spec that
 exercises the troublesome code path, then run it using the `bin/rspec-stackprof`
 helper, e.g.:
-```
+```sh
 $ LIMIT=10 bin/rspec-stackprof spec/policies/project_policy_spec.rb
 8/8 |====== 100 ======>| Time: 00:00:18
@@ -157,22 +157,22 @@ it calls, were being executed.
 To create a graphical view of the call stack:
-```shell
-$ stackprof tmp/project_policy_spec.rb.dump --graphviz > project_policy_spec.dot
-$ dot -Tsvg project_policy_spec.dot > project_policy_spec.svg
+```sh
+stackprof tmp/project_policy_spec.rb.dump --graphviz > project_policy_spec.dot
+dot -Tsvg project_policy_spec.dot > project_policy_spec.svg
 ```
 To load the profile in [kcachegrind](https://kcachegrind.github.io/):
-```
-$ stackprof tmp/project_policy_spec.dump --callgrind > project_policy_spec.callgrind
-$ kcachegrind project_policy_spec.callgrind # Linux
-$ qcachegrind project_policy_spec.callgrind # Mac
+```sh
+stackprof tmp/project_policy_spec.dump --callgrind > project_policy_spec.callgrind
+kcachegrind project_policy_spec.callgrind # Linux
+qcachegrind project_policy_spec.callgrind # Mac
 ```
 It may be useful to zoom in on a specific method, e.g.:
-```
+```sh
 $ stackprof tmp/project_policy_spec.rb.dump --method warm_asset_cache
 TestEnv#warm_asset_cache (/Users/lupine/dev/gitlab.com/gitlab-org/gitlab-development-kit/gitlab/spec/support/test_env.rb:164)
   samples:     0 self (0.0%)  /   6288 total (36.9%)
@@ -225,9 +225,9 @@ may have changed over time.
 To activate profiling in your local environment, run the following:
-```
-$ export RSPEC_PROFILING=yes
-$ rake rspec_profiling:install
+```sh
+export RSPEC_PROFILING=yes
+rake rspec_profiling:install
 ```
 This creates an SQLite3 database in `tmp/rspec_profiling`, into which statistics
@@ -237,7 +237,7 @@ variable set.
 Ad-hoc investigation of the collected results can be performed in an interactive
 shell:
-```
+```sh
 $ rake rspec_profiling:console
 irb(main):001:0> results.count
 => 231

doc/development/testing_guide/frontend_testing.md

@@ -20,9 +20,18 @@ We have started to migrate frontend tests to the [Jest](https://jestjs.io) testi
 Jest tests can be found in `/spec/frontend` and `/ee/spec/frontend` in EE.
-It is not yet a requirement to use Jest. You can view the
-[epic](https://gitlab.com/groups/gitlab-org/-/epics/873) of issues
-we need to solve before being able to use Jest for all our needs.
+### When should I use Jest over Karma?
+
+If you need to update an existing Karma test file (found in `spec/javascripts`), you do not
+need to migrate the whole spec to Jest. Simply updating the Karma spec to test your change
+is fine. It is probably more appropriate to migrate to Jest in a separate merge request.
+
+If you need to create a new test file, we strongly recommend creating one in Jest. This will
+help support our migration and we think you'll love using Jest.
+
+As always, please use discretion. Jest solves a lot of issues we experienced in Karma and
+provides a better developer experience, however there are potentially unexpected issues
+which could arise (especially with testing against browser specific features).
 ### Differences to Karma

doc/downgrade_ee_to_ce/README.md

@@ -47,14 +47,14 @@ to avoid getting this error, you need to remove all instances of the
 **Omnibus Installation**
-```
-$ sudo gitlab-rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all"
+```sh
+sudo gitlab-rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all"
 ```
 **Source Installation**
-```
-$ bundle exec rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all" production
+```sh
+bundle exec rails runner "Service.where(type: ['JenkinsService', 'JenkinsDeprecatedService', 'GithubService']).delete_all" production
 ```
 ### Variables environment scopes
@@ -89,10 +89,10 @@ To downgrade a source installation, you need to replace the current remote of
 your GitLab installation with the Community Edition's remote, fetch the latest
 changes, and checkout the latest stable branch:
-```
-$ git remote set-url origin git@gitlab.com:gitlab-org/gitlab-ce.git
-$ git fetch --all
-$ git checkout 8-x-stable
+```sh
+git remote set-url origin git@gitlab.com:gitlab-org/gitlab-ce.git
+git fetch --all
+git checkout 8-x-stable
 ```
 Remember to follow the correct [update guides](../update/README.md) to make

doc/install/aws/index.md

@@ -613,6 +613,9 @@ To back up GitLab:
    sudo gitlab-backup create
    ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 ### Restoring GitLab from a backup
 To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.md#restore),
@@ -631,6 +634,9 @@ released, you can update your GitLab instance:
    sudo gitlab-backup create
    ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 1. Update the repositories and install GitLab:
    ```sh

doc/install/openshift_and_gitlab/index.md

@@ -225,7 +225,7 @@ First, we will create a new project to host our application. You can do this
 either by running the CLI client:
 ```bash
-$ oc new-project gitlab
+oc new-project gitlab
 ```
 or by using the web interface:

doc/integration/github.md

@@ -158,7 +158,7 @@ For installation from source:
 You will also need to disable Git SSL verification on the server hosting GitLab.
 ```
-$ git config --global http.sslVerify false
+git config --global http.sslVerify false
 ```
 For the changes to take effect, [reconfigure GitLab] if you installed

doc/migrate_ci_to_ce/README.md

@@ -77,6 +77,9 @@ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production SKIP=r
 If this fails you need to fix it before upgrading to 8.0. Also see
 <https://about.gitlab.com/get-help/>
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 ### 2. Check source and target database types
 Check what databases you use on your GitLab server and your CI server.

doc/raketasks/backup_restore.md

@@ -80,6 +80,9 @@ Use this command if you've installed GitLab with the Omnibus package:
 sudo gitlab-backup create
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 Use this if you've installed GitLab from source:
 ```sh
@@ -92,6 +95,9 @@ If you are running GitLab within a Docker container, you can run the backup from
 docker exec -t <container name> gitlab-backup create
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 If you are using the [GitLab helm chart](https://gitlab.com/gitlab-org/charts/gitlab) on a
 Kubernetes cluster, you can run the backup task using `backup-utility` script on
 the GitLab task runner pod via `kubectl`. Refer to [backing up a GitLab installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/backup.md#backing-up-a-gitlab-installation) for more details:
@@ -202,6 +208,9 @@ To use the `copy` strategy instead of the default streaming strategy, specify
 sudo gitlab-backup create STRATEGY=copy
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 ### Backup filename
 By default a backup file is created according to the specification in [the Backup timestamp](#backup-timestamp) section above. You can however override the `[TIMESTAMP]` part of the filename by setting the `BACKUP` environment variable. For example:
@@ -210,6 +219,9 @@ By default a backup file is created according to the specification in [the Backu
 sudo gitlab-backup create BACKUP=dump
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 The resulting file will then be `dump_gitlab_backup.tar`. This is useful for systems that make use of rsync and incremental backups, and will result in considerably faster transfer speeds.
 ### Rsyncable
@@ -222,6 +234,9 @@ Note that the `--rsyncable` option in `gzip` is not guaranteed to be available o
 sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 ### Excluding specific directories from the backup
 You can choose what should be exempt from the backup up by adding the environment variable `SKIP`.
@@ -247,6 +262,9 @@ For Omnibus GitLab packages:
 sudo gitlab-backup create SKIP=db,uploads
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 For installations from source:
 ```sh
@@ -452,6 +470,9 @@ sudo gitlab-backup create DIRECTORY=daily
 sudo gitlab-backup create DIRECTORY=weekly
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 ### Uploading to locally mounted shares
 You may also send backups to a mounted share (`NFS` / `CIFS` / `SMB` / etc.) by
@@ -569,6 +590,9 @@ There, add the following line to schedule the backup for everyday at 2 AM:
 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
+
 You may also want to set a limited lifetime for backups to prevent regular
 backups using all your disk space.
@@ -729,6 +753,14 @@ restore:
 sudo gitlab-backup restore BACKUP=1493107454_2018_04_25_10.6.4-ce
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:restore`.
+
+CAUTION: **Warning:**
+`gitlab-rake gitlab:backup:restore` does not set the right file system permissions on your Registry directory.
+This is a [known issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/62759). On GitLab 12.2 or newer, you can
+use `gitlab-backup restore` to avoid this issue.
+
 Next, restore `/etc/gitlab/gitlab-secrets.json` if necessary as mentioned above.
 Reconfigure, restart and check GitLab:
@@ -763,6 +795,14 @@ For docker installations, the restore task can be run from host:
 docker exec -it <name of container> gitlab-backup restore
 ```
+NOTE: **Note**
+For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:restore`.
+
+CAUTION: **Warning:**
+`gitlab-rake gitlab:backup:restore` does not set the right file system permissions on your Registry directory.
+This is a [known issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/62759). On GitLab 12.2 or newer, you can
+use `gitlab-backup restore` to avoid this issue.
+
 The GitLab helm chart uses a different process, documented in
 [restoring a GitLab helm chart installation](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/doc/backup-restore/restore.md).
@@ -978,7 +1018,7 @@ sudo chown -R registry:registry /var/opt/gitlab/gitlab-rails/shared/registry/doc
 NOTE: **Note:**
 If you have changed the default filesystem location for the registry, you will
-want to run the chown against your custom location instead of
+want to run the `chown` against your custom location instead of
 `/var/opt/gitlab/gitlab-rails/shared/registry/docker`.
 [reconfigure GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
@@ -990,6 +1030,7 @@ While running the backup, you may receive a gzip error:
 ```sh
 sudo /opt/gitlab/bin/gitlab-backup create
+...
 Dumping ...
 ...
 gzip: stdout: Input/output error
@@ -999,5 +1040,5 @@ Backup failed
 If this happens, check the following:
-1. Confirm there is sufficent diskspace for the gzip operation.
-1. If NFS is being used, check if the mount option `timeo` is set. The default is `600`, and changing this to smaller values have resulted in this error.
+1. Confirm there is sufficient disk space for the gzip operation.
+1. If NFS is being used, check if the mount option `timeout` is set. The default is `600`, and changing this to smaller values have resulted in this error.

doc/raketasks/import.md

@@ -42,17 +42,17 @@ If you are using an installation from source, replace `/var/opt/gitlab/` with `/
 #### Omnibus Installation
-```
-$ sudo gitlab-rake gitlab:import:repos['/var/opt/gitlab/git-data/repository-import-<date>']
+```sh
+sudo gitlab-rake gitlab:import:repos['/var/opt/gitlab/git-data/repository-import-<date>']
 ```
 #### Installation from source
 Before running this command you need to change the directory to where your GitLab installation is located:
-```
-$ cd /home/git/gitlab
-$ sudo -u git -H bundle exec rake gitlab:import:repos['/var/opt/gitlab/git-data/repository-import-<date>'] RAILS_ENV=production
+```sh
+cd /home/git/gitlab
+sudo -u git -H bundle exec rake gitlab:import:repos['/var/opt/gitlab/git-data/repository-import-<date>'] RAILS_ENV=production
 ```
 #### Example output

doc/security/asset_proxy.md

+# Proxying assets
+
 A possible security concern when managing a public facing GitLab instance is
 the ability to steal a users IP address by referencing images in issues, comments, etc.
 For example, adding `![Example image](http://example.com/example.png)` to
 an issue description will cause the image to be loaded from the external
-server in order to be displayed.  However this also allows the external server
+server in order to be displayed. However, this also allows the external server
 to log the IP address of the user.
 One way to mitigate this is by proxying any external images to a server you
-control.  GitLab handles this by allowing you to run the "Camo" server
-[cactus/go-camo](https://github.com/cactus/go-camo#how-it-works).
-The image request is sent to the Camo server, which then makes the request for
-the original image.  This way an attacker only ever seems the IP address
-of your Camo server.
-Once you have your Camo server up and running, you can configure GitLab to
-proxy image requests to it.  The following settings are supported:
-| Attribute                 | Description |
-| ------------------------- | ----------- |
-| `asset_proxy_enabled`     | (**If enabled, requires:** `asset_proxy_url`) Enable proxying of assets. |
-| `asset_proxy_secret_key`  | Shared secret with the asset proxy server. |
-| `asset_proxy_url`         | URL of the asset proxy server. |
-| `asset_proxy_whitelist`   | Assets that match these domain(s) will NOT be proxied. Wildcards allowed. Your GitLab installation URL is automatically whitelisted. |
-These can be set via the [Application setting API](../api/settings.md)
-Note that a GitLab restart is required to apply any changes.
+control.
+
+GitLab can be configured to use an asset proxy server when requesting external images/videos in
+issues, comments, etc. This helps ensure that malicious images do not expose the user's IP address
+when they are fetched.
+
+We currently recommend using [cactus/go-camo](https://github.com/cactus/go-camo#how-it-works)
+as it supports proxying video and is more configurable.
+
+## Installing Camo server
+
+A Camo server is used to act as the proxy.
+
+To install a Camo server as an asset proxy:
+
+1. Deploy a `go-camo` server. Helpful instructions can be found in
+   [building catus/go-camo](https://github.com/cactus/go-camo#building).
+
+1. Make sure your instance of GitLab is running, and that you have created a private API token.
+   Using the API, configure the asset proxy settings on your GitLab instance. For example:
+
+    ```sh
+    curl --request "PUT" "https://gitlab.example.com/api/v4/application/settings?\
+    asset_proxy_enabled=true&\
+    asset_proxy_url=https://proxy.gitlab.example.com&\
+    asset_proxy_secret_key=<somekey>" \
+    --header 'PRIVATE-TOKEN: <my_private_token>'
+    ```
+
+    The following settings are supported:
+
+    | Attribute                | Description                                                                                                                          |
+    |:-------------------------|:-------------------------------------------------------------------------------------------------------------------------------------|
+    | `asset_proxy_enabled`    | Enable proxying of assets. If enabled, requires: `asset_proxy_url`).                                                                 |
+    | `asset_proxy_secret_key` | Shared secret with the asset proxy server.                                                                                           |
+    | `asset_proxy_url`        | URL of the asset proxy server.                                                                                                       |
+    | `asset_proxy_whitelist`  | Assets that match these domain(s) will NOT be proxied. Wildcards allowed. Your GitLab installation URL is automatically whitelisted. |
+
+1. Restart the server for the changes to take effect. Each time you change any values for the asset
+   proxy, you need to restart the server.
+
+## Using the Camo server
+
+Once the Camo server is running and you've enabled the GitLab settings, any image or video that
+references an external source will get proxied to the Camo server.
+For example, the following is a link to an image in Markdown:
+```markdown
+![logo](https://about.gitlab.com/images/press/logo/jpg/gitlab-icon-rgb.jpg)
+```
+The following is an example of a source link that could result:
+```text
+http://proxy.gitlab.example.com/f9dd2b40157757eb82afeedbf1290ffb67a3aeeb/68747470733a2f2f61626f75742e6769746c61622e636f6d2f696d616765732f70726573732f6c6f676f2f6a70672f6769746c61622d69636f6e2d7267622e6a7067
+```

doc/user/application_security/dependency_scanning/index.md

@@ -4,8 +4,11 @@ type: reference, howto
 # Dependency Scanning **(ULTIMATE)**
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5105)
-in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5105) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 10.7.
+
+Dependency Scanning helps to automatically find security vulnerabilities in your dependencies
+while you are developing and testing your applications, for example when your
+application is using an external (open source) library which is known to be vulnerable.
 ## Overview
@@ -18,7 +21,7 @@ in your existing `.gitlab-ci.yml` file or by implicitly using
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
 GitLab checks the Dependency Scanning report, compares the found vulnerabilities
-between the source and target branches, and shows the information right on the
+between the source and target branches, and shows the information on the
 merge request.
 ![Dependency Scanning Widget](img/dependency_scanning.png)
@@ -32,12 +35,6 @@ The results are sorted by the severity of the vulnerability:
 1. Unknown
 1. Everything else
-## Use cases
-
-It helps to automatically find security vulnerabilities in your dependencies
-while you are developing and testing your applications. For example when your
-application is using an external (open source) library which is known to be vulnerable.
-
 ## Requirements
 To run a Dependency Scanning job, you need GitLab Runner with the
@@ -146,7 +143,7 @@ Dependency Scanning can be [configured](#customizing-the-dependency-scanning-set
 using environment variables.
 | Environment variable                    | Description | Example usage |
-|--------------------------------         |-------------| |
+| --------------------------------------- | ----------- | ------------- |
 | `DS_ANALYZER_IMAGES`                    | Comma separated list of custom images. The official default images are still enabled. Read more about [customizing analyzers](analyzers.md). | |
 | `DS_ANALYZER_IMAGE_PREFIX`              | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). | |
 | `DS_ANALYZER_IMAGE_TAG`                 | Override the Docker tag of the official default images. Read more about [customizing analyzers](analyzers.md). | |
@@ -162,10 +159,39 @@ using environment variables.
 | `PIP_INDEX_URL`                         | Base URL of Python Package Index (default `https://pypi.org/simple`). | |
 | `PIP_EXTRA_INDEX_URL`                   | Array of [extra URLs](https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-extra-index-url) of package indexes to use in addition to `PIP_INDEX_URL`. Comma separated. | |
+## Interacting with the vulnerabilities
+
+Once a vulnerability is found, you can interact with it. Read more on how to
+[interact with the vulnerabilities](../index.md#interacting-with-the-vulnerabilities).
+
+## Solutions for vulnerabilities (auto-remediation)
+
+Some vulnerabilities can be fixed by applying the solution that GitLab
+automatically generates.
+
+Read more about the [solutions for vulnerabilities](../index.md#solutions-for-vulnerabilities-auto-remediation).
+
+## Security Dashboard
+
+The Security Dashboard is a good place to get an overview of all the security
+vulnerabilities in your groups, projects and pipelines. Read more about the
+[Security Dashboard](../security_dashboard/index.md).
+
+## Vulnerabilities database update
+
+For more information about the vulnerabilities database update, check the
+[maintenance table](../index.md#maintenance-and-update-of-the-vulnerabilities-database).
+
+## Dependency List
+
+An additional benefit of Dependency Scanning is the ability to view your
+project's dependencies and their known vulnerabilities. Read more about
+the [Dependency List](../dependency_list/index.md).
+
 ## Reports JSON format
 CAUTION: **Caution:**
-The JSON report artifacts are not a public API of Dependency Scanning and their format may change in future.
+The JSON report artifacts are not a public API of Dependency Scanning and their format may change in the future.
 The Dependency Scanning tool emits a JSON report file. Here is an example of the report structure with all important parts of
 it highlighted:
@@ -315,28 +341,6 @@ the report JSON unless stated otherwise. Presence of optional fields depends on
 | `remediations[].summary`                             | Overview of how the vulnerabilities have been fixed. |
 | `remediations[].diff`                                | base64-encoded remediation code diff, compatible with [`git apply`](https://git-scm.com/docs/git-format-patch#_discussion). |
-## Security Dashboard
-
-The Security Dashboard is a good place to get an overview of all the security
-vulnerabilities in your groups, projects and pipelines. Read more about the
-[Security Dashboard](../security_dashboard/index.md).
-
-## Interacting with the vulnerabilities
-
-Once a vulnerability is found, you can interact with it. Read more on how to
-[interact with the vulnerabilities](../index.md#interacting-with-the-vulnerabilities).
-
-## Vulnerabilities database update
-
-For more information about the vulnerabilities database update, check the
-[maintenance table](../index.md#maintenance-and-update-of-the-vulnerabilities-database).
-
-## Dependency List **(ULTIMATE)**
-
-An additional benefit of Dependency Scanning is the ability to view your
-project's dependencies and their known vulnerabilities. Read more about
-the [Dependency List](../dependency_list/index.md).
-
 ## Versioning and release process
 Please check the [Release Process documentation](https://gitlab.com/gitlab-org/security-products/release/blob/master/docs/release_process.md).

doc/user/application_security/index.md

@@ -71,8 +71,7 @@ entry, a detailed information will pop up with different possible options:
 - [Create issue](#creating-an-issue-for-a-vulnerability): The new issue will
   have the title and description pre-populated with the information from the
   vulnerability report and will be created as [confidential](../project/issues/confidential_issues.md) by default.
-- [Solution](#solutions-for-vulnerabilities): For some vulnerabilities
-  ([Dependency Scanning](dependency_scanning/index.md) and [Container Scanning](container_scanning/index.md))
+- [Solution](#solutions-for-vulnerabilities-auto-remediation): For some vulnerabilities,
   a solution is provided for how to fix the vulnerability.
 ![Interacting with security reports](img/interactive_reports.png)
@@ -109,17 +108,16 @@ the vulnerability will now have an associated issue next to the name.
 ![Linked issue in the group security dashboard](img/issue.png)
-### Solutions for vulnerabilities
-> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.7.
-
-CAUTION: **Warning:**
-Automatic Patch creation is only available for a subset of
-[Dependency Scanning](dependency_scanning/index.md). At the moment only Node.JS
-projects managed with yarn are supported.
+### Solutions for vulnerabilities (auto-remediation)
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/5656) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.7.
 Some vulnerabilities can be fixed by applying the solution that GitLab
-automatically generates.
+automatically generates. The following scanners are supported:
+
+- [Dependency Scanning](dependency_scanning/index.md):
+  Automatic Patch creation is only available for Node.JS projects managed with
+  `yarn`.
 #### Manually applying the suggested patch
@@ -136,13 +134,12 @@ generated by GitLab. To apply the fix:
 #### Creating a merge request from a vulnerability
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9224) in
-> [GitLab Ultimate](https://about.gitlab.com/pricing) 11.9.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9224) in [GitLab Ultimate](https://about.gitlab.com/pricing) 11.9.
 In certain cases, GitLab will allow you to create a merge request that will
 automatically remediate the vulnerability. Any vulnerability that has a
-[solution](#solutions-for-vulnerabilities) can have a merge request created to
-automatically solve the issue.
+[solution](#solutions-for-vulnerabilities-auto-remediation) can have a merge
+request created to automatically solve the issue.
 If this action is available there will be a **Create merge request** button in the vulnerability modal.
 Clicking on this button will create a merge request to apply the solution onto the source branch.

doc/user/markdown.md

@@ -1292,7 +1292,7 @@ Example:
 Additionally, you can choose the alignment of text within columns by adding colons (`:`)
 to the sides of the "dash" lines in the second row. This will affect every cell in the column.
-> Note that the headers are always right aligned [within GitLab itself itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#tables).
+> Note that the headers are always right aligned [within GitLab itself](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/user/markdown.md#tables).
 ```markdown
 | Left Aligned | Centered | Right Aligned | Left Aligned | Centered | Right Aligned |

doc/user/profile/account/create_accounts.md

+---
+type: reference
+---
+
+# Creating users **(CORE ONLY)**
+
+You can create users:
+
+- Manually through the sign in page or Admin Area.
+- Automatically through user authentication integrations.
+
+## Create users on sign in page
+
+If you have [sign-up enabled](../../admin_area/settings/sign_up_restrictions.md), users can create their own accounts using the **Register** tab on the sign in page.
+
+![Register Tab](img/register_tab.png)
+
+## Create users in admin area
+
+As an admin user, you can manually create users by:
+
+1. Navigating to **Admin Area > Overview > Users** (`/admin/users` page).
+1. Selecting the **New User** button.
+
+You can also [create users through the API](../../../api/users.md) as an admin.
+
+![Admin User Button](img/admin_user_button.png)
+
+![Admin User Form](img/admin_user_form.png)
+
+## Create users through integrations
+
+Users will be:
+
+- Automatically created upon first login with the [LDAP integration](../../../administration/auth/ldap.md).
+- Created when first logging in via an [OmniAuth provider](../../../integration/omniauth.md) if the `allow_single_sign_on` setting is present.

doc/user/profile/index.md

@@ -8,6 +8,10 @@ Each GitLab account has a user profile, and settings. Your [profile](#user-profi
 contains information about you, and your GitLab activity. Your [settings](#profile-settings)
 allow you to customize some aspects of GitLab to suit yourself.
+## Creating users
+
+There are several ways to create users on GitLab. See the [creating users documentation](account/create_accounts.md) for more details.
+
 ## Signing in
 There are several ways to sign into your GitLab account.

doc/user/project/canary_deployments.md

@@ -2,7 +2,7 @@
 > [Introduced][ee-1659] in [GitLab Premium][eep] 9.1.
-A popular [Continuous Integration](https://en.wikipedia.org/wiki/Continuous_integration)
+A popular [Continuous Deployment](https://en.wikipedia.org/wiki/Continuous_deployment)
 strategy, where a small portion of the fleet is updated to the new version of
 your application.

doc/user/project/integrations/webhooks.md

@@ -1327,3 +1327,6 @@ console:
 example.com - - [14/May/2014:07:45:26 EDT] "POST / HTTP/1.1" 200 0
 - -> /
 ```
+
+NOTE: **Note:**
+You may need to [allow requests to the local network](../../../security/webhooks.md) for this receiver to be added.