Merge branch 'master' into bootstrap4

13 files changed, 180 insertions, 50 deletions

diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index d8928a7fe4c..ad8ffc46559 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -75,43 +75,33 @@ Notice several options that you should consider using:
 | `nobootwait` | Don't halt boot process waiting for this mount to become available
 | `lookupcache=positive` | Tells the NFS client to honor `positive` cache results but invalidates any `negative` cache results. Negative cache results cause problems with Git. Specifically, a `git push` can fail to register uniformly across all NFS clients. The negative cache causes the clients to 'remember' that the files did not exist previously.
 
-## Mount locations
+## A single NFS mount
 
-When using default Omnibus configuration you will need to share 5 data locations
-between all GitLab cluster nodes. No other locations should be shared. The
-following are the 5 locations you need to mount:
-
-| Location | Description | Default configuration |
-| -------- | ----------- | --------------------- |
-| `/var/opt/gitlab/git-data` | Git repository data. This will account for a large portion of your data | `git_data_dirs({"default" => "/var/opt/gitlab/git-data"})`
-| `/var/opt/gitlab/.ssh` | SSH `authorized_keys` file and keys used to import repositories from some other Git services | `user['home'] = '/var/opt/gitlab/'`
-| `/var/opt/gitlab/gitlab-rails/uploads` | User uploaded attachments | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'`
-| `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'`
-| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'`
+It's recommended to nest all gitlab data dirs within a mount, that allows automatic
+restore of backups without manually moving existing data.
 
-Other GitLab directories should not be shared between nodes. They contain
-node-specific files and GitLab code that does not need to be shared. To ship
-logs to a central location consider using remote syslog. GitLab Omnibus packages
-provide configuration for [UDP log shipping][udp-log-shipping].
-
-### Consolidating mount points
-
-If you don't want to configure 5-6 different NFS mount points, you have a few
-alternative options.
+```
+mountpoint
+└── gitlab-data
+    ├── builds
+    ├── git-data
+    ├── home-git
+    ├── shared
+    └── uploads
+```
 
-#### Change default file locations
+To do so, we'll need to configure Omnibus with the paths to each directory nested
+in the mount point as follows:
 
-Omnibus allows you to configure the file locations. With custom configuration
-you can specify just one main mountpoint and have all of these locations
-as subdirectories. Mount `/gitlab-data` then use the following Omnibus
+Mount `/gitlab-nfs` then use the following Omnibus
 configuration to move each data location to a subdirectory:
 
 ```ruby
-git_data_dirs({"default" => "/gitlab-data/git-data"})
-user['home'] = '/gitlab-data/home'
-gitlab_rails['uploads_directory'] = '/gitlab-data/uploads'
-gitlab_rails['shared_path'] = '/gitlab-data/shared'
-gitlab_ci['builds_directory'] = '/gitlab-data/builds'
+git_data_dirs({"default" => "/gitlab-nfs/gitlab-data/git-data"})
+user['home'] = '/gitlab-nfs/gitlab-data/home'
+gitlab_rails['uploads_directory'] = '/gitlab-nfs/gitlab-data/uploads'
+gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared'
+gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds'
 ```
 
 To move the `git` home directory, all GitLab services must be stopped. Run
@@ -122,22 +112,52 @@ Run `sudo gitlab-ctl reconfigure` to start using the central location. Please
 be aware that if you had existing data you will need to manually copy/rsync it
 to these new locations and then restart GitLab.
 
-#### Bind mounts
+## Bind mounts
+
+Alternatively to changing the configuration in Omnibus, bind mounts can be used
+to store the data on an NFS mount.
 
 Bind mounts provide a way to specify just one NFS mount and then
 bind the default GitLab data locations to the NFS mount. Start by defining your
 single NFS mount point as you normally would in `/etc/fstab`. Let's assume your
-NFS mount point is `/gitlab-data`. Then, add the following bind mounts in
+NFS mount point is `/gitlab-nfs`. Then, add the following bind mounts in
 `/etc/fstab`:
 
 ```bash
-/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
-/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
-/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0
-/gitlab-data/shared /var/opt/gitlab/gitlab-rails/shared none bind 0 0
-/gitlab-data/builds /var/opt/gitlab/gitlab-ci/builds none bind 0 0
+/gitlab-nfs/gitlab-data/git-data /var/opt/gitlab/git-data none bind 0 0
+/gitlab-nfs/gitlab-data/.ssh /var/opt/gitlab/.ssh none bind 0 0
+/gitlab-nfs/gitlab-data/uploads /var/opt/gitlab/gitlab-rails/uploads none bind 0 0
+/gitlab-nfs/gitlab-data/shared /var/opt/gitlab/gitlab-rails/shared none bind 0 0
+/gitlab-nfs/gitlab-data/builds /var/opt/gitlab/gitlab-ci/builds none bind 0 0
 ```
 
+Using bind mounts will require manually making sure the data directories
+are empty before attempting a restore. Read more about the
+[restore prerequisites](../../raketasks/backup_restore.md).
+
+## Multiple NFS mounts
+
+When using default Omnibus configuration you will need to share 5 data locations
+between all GitLab cluster nodes. No other locations should be shared. The
+following are the 5 locations need to be shared:
+
+| Location | Description | Default configuration |
+| -------- | ----------- | --------------------- |
+| `/var/opt/gitlab/git-data` | Git repository data. This will account for a large portion of your data | `git_data_dirs({"default" => "/var/opt/gitlab/git-data"})`
+| `/var/opt/gitlab/.ssh` | SSH `authorized_keys` file and keys used to import repositories from some other Git services | `user['home'] = '/var/opt/gitlab/'`
+| `/var/opt/gitlab/gitlab-rails/uploads` | User uploaded attachments | `gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'`
+| `/var/opt/gitlab/gitlab-rails/shared` | Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you're using LFS this may also account for a large portion of your data | `gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'`
+| `/var/opt/gitlab/gitlab-ci/builds` | GitLab CI build traces | `gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'`
+
+Other GitLab directories should not be shared between nodes. They contain
+node-specific files and GitLab code that does not need to be shared. To ship
+logs to a central location consider using remote syslog. GitLab Omnibus packages
+provide configuration for [UDP log shipping][udp-log-shipping].
+
+Having multiple NFS mounts will require manually making sure the data directories
+are empty before attempting a restore. Read more about the
+[restore prerequisites](../../raketasks/backup_restore.md).
+
 ---
 
 Read more on high-availability configuration:
diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index b3d9f0bc96c..517e25f00f7 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -260,6 +260,8 @@ are unsupported in environment name context:
 - `CI_REGISTRY_PASSWORD`
 - `CI_REPOSITORY_URL`
 - `CI_ENVIRONMENT_URL`
+- `CI_DEPLOY_USER`
+- `CI_DEPLOY_PASSWORD`
 
 GitLab Runner exposes various [environment variables][variables] when a job runs,
 and as such, you can use them as environment names. Let's add another job in
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index 60dc2ef9ac5..821413900fd 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -298,6 +298,28 @@ Mentioned briefly earlier, but the following things of Runners can be exploited.
 We're always looking for contributions that can mitigate these
 [Security Considerations](https://docs.gitlab.com/runner/security/).
 
+### Resetting the registration token for a Project
+
+If you think that registration token for a Project was revealed, you should
+reset them. It's recommended because such token can be used to register another
+Runner to thi Project. It may be next used to obtain the values of secret
+variables or clone the project code, that normally may be unavailable for the
+attacker.
+
+To reset the token:
+
+1. Go to **Settings > CI/CD** for a specified Project
+1. Expand the **General pipelines settings** section
+1. Find the **Runner token** form field and click the **Reveal value** button
+1. Delete the value and save the form
+1. After the page is refreshed, expand the **Runners settings** section
+    and check the registration token - it should be changed
+
+From now on the old token is not valid anymore and will not allow to register
+a new Runner to the project. If you are using any tools to provision and
+register new Runners, you should now update the token that is used to the
+new value.
+
 ## Determining the IP address of a Runner
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17286) in GitLab 10.6.
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index 4a504a98902..f0df8b96cab 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -87,6 +87,8 @@ future GitLab releases.**
 | **GITLAB_USER_LOGIN**           | 10.0   | all    | The login username of the user who started the job |
 | **GITLAB_USER_NAME**            | 10.0   | all    | The real name of the user who started the job |
 | **RESTORE_CACHE_ATTEMPTS**      | 8.15   | 1.9    | Number of attempts to restore the cache running a job |
+| **CI_DEPLOY_USER**              | 10.8   | all    | Authentication username of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related.|
+| **CI_DEPLOY_PASSWORD**          | 10.8   | all    | Authentication password of the [GitLab Deploy Token][gitlab-deploy-token], only present if the Project has one related.|
 
 ## 9.0 Renaming
 
@@ -546,6 +548,8 @@ You can find a full list of unsupported variables below:
 - `CI_REGISTRY_PASSWORD`
 - `CI_REPOSITORY_URL`
 - `CI_ENVIRONMENT_URL`
+- `CI_DEPLOY_USER`
+- `CI_DEPLOY_PASSWORD`
 
 These variables are also not supported in a contex of a
 [dynamic environment name][dynamic-environments].
@@ -562,3 +566,4 @@ These variables are also not supported in a contex of a
 [subgroups]: ../../user/group/subgroups/index.md
 [builds-policies]: ../yaml/README.md#only-and-except-complex
 [dynamic-environments]: ../environments.md#dynamic-environments
+[gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 623e7d662a3..fb6d9826d08 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -1573,7 +1573,7 @@ capitalization, the commit will be created but the pipeline will be skipped.
 
 Each instance of GitLab CI has an embedded debug tool called Lint, which validates the
 content of your `.gitlab-ci.yml` files. You can find the Lint under the page `ci/lint` of your 
-project namespace (e.g, `http://gitlab-example.com/gitlab-org/project-123/ci/lint`)
+project namespace (e.g, `http://gitlab-example.com/gitlab-org/project-123/-/ci/lint`)
 
 ## Using reserved keywords
 
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 0a6f402d5d2..af477f5ab99 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -126,13 +126,51 @@ it('tests a promise rejection', (done) => {
 });
 ```
 
-#### Stubbing
+#### Stubbing and Mocking
 
-For unit tests, you should stub methods that are unrelated to the current unit you are testing.
-If you need to use a prototype method, instantiate an instance of the class and call it there instead of mocking the instance completely.
+Jasmine provides useful helpers `spyOn`, `spyOnProperty`, `jasmine.createSpy`,
+and `jasmine.createSpyObject` to facilitate replacing methods with dummy
+placeholders, and recalling when they are called and the arguments that are
+passed to them. These tools should be used liberally, to test for expected
+behavior, to mock responses, and to block unwanted side effects (such as a
+method that would generate a network request or alter `window.location`). The
+documentation for these methods can be found in the [jasmine introduction page](https://jasmine.github.io/2.0/introduction.html#section-Spies).
 
-For integration tests, you should stub methods that will effect the stability of the test if they
-execute their original behaviour. i.e. Network requests.
+Sometimes you may need to spy on a method that is directly imported by another
+module. GitLab has a custom `spyOnDependency` method which utilizes
+[babel-plugin-rewire](https://github.com/speedskater/babel-plugin-rewire) to
+achieve this.  It can be used like so:
+
+```javascript
+// my_module.js
+import { visitUrl } from '~/lib/utils/url_utility';
+
+export default function doSomething() {
+  visitUrl('/foo/bar');
+}
+
+// my_module_spec.js
+import doSomething from '~/my_module';
+
+describe('my_module', () => {
+  it('does something', () => {
+    const visitUrl = spyOnDependency(doSomething, 'visitUrl');
+
+    doSomething();
+    expect(visitUrl).toHaveBeenCalledWith('/foo/bar');
+  });
+});
+```
+
+Unlike `spyOn`, `spyOnDependency` expects its first parameter to be the default
+export of a module who's import you want to stub, rather than an object which
+contains a method you wish to stub (if the module does not have a default
+export, one is be generated by the babel plugin). The second parameter is the
+name of the import you wish to change. The result of the function is a Spy
+object which can be treated like any other jasmine spy object.
+
+Further documentation on the babel rewire pluign API can be found on
+[its repository Readme doc](https://github.com/speedskater/babel-plugin-rewire#babel-plugin-rewire).
 
 ### Vue.js unit tests
 
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index bbd2d214fe4..785cc32d590 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -498,6 +498,13 @@ more of the following options:
   Read what the [backup timestamp is about](#backup-timestamp).
 - `force=yes` - Does not ask if the authorized_keys file should get regenerated and assumes 'yes' for warning that database tables will be removed.
 
+If you are restoring into directories that are mountpoints you will need to make
+sure these directories are empty before attempting a restore. Otherwise GitLab
+will attempt to move these directories before restoring the new data and this
+would cause an error.
+
+Read more on [configuring NFS mounts](../administration/high_availability/nfs.md)
+
 ### Restore for installation from source
 
 ```
diff --git a/doc/security/img/outbound_requests_section.png b/doc/security/img/outbound_requests_section.png
new file mode 100644
index 00000000000..95c9c6ee771
--- /dev/null
+++ b/doc/security/img/outbound_requests_section.png
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index faabc53ce72..a573445ab5b 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -2,12 +2,19 @@
 
 If you have non-GitLab web services running on your GitLab server or within its local network, these may be vulnerable to exploitation via Webhooks.
 
-With [Webhooks](../user/project/integrations/webhooks.md), you and your project masters and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way. 
+With [Webhooks](../user/project/integrations/webhooks.md), you and your project masters and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way.
 
 Things get hairy, however, when a Webhook is set up with a URL that doesn't point to an external, but to an internal service, that may do something completely unintended when the webhook is triggered and the POST request is sent.
 
 Because Webhook requests are made by the GitLab server itself, these have complete access to everything running on the server (http://localhost:123) or within the server's local network (http://192.168.1.12:345), even if these services are otherwise protected and inaccessible from the outside world.
 
-If a web service does not require authentication, Webhooks can be used to trigger destructive commands by getting the GitLab server to make POST requests to endpoints like "http://localhost:123/some-resource/delete". 
+If a web service does not require authentication, Webhooks can be used to trigger destructive commands by getting the GitLab server to make POST requests to endpoints like "http://localhost:123/some-resource/delete".
 
-To prevent this type of exploitation from happening, make sure that you are aware of every web service GitLab could potentially have access to, and that all of these are set up to require authentication for every potentially destructive command. Enabling authentication but leaving a default password is not enough.
+To prevent this type of exploitation from happening, starting with GitLab 10.6, all Webhook requests to the current GitLab instance server address and/or in a private network will be forbidden by default. That means that all requests made to 127.0.0.1, ::1 and 0.0.0.0, as well as IPv4 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and IPv6 site-local (ffc0::/10) addresses won't be allowed.
+
+This behavior can be overridden by enabling the option *"Allow requests to the local network from hooks and services"* in the *"Outbound requests"* section inside the Admin area under **Settings** (`/admin/application_settings`):
+
+![Outbound requests admin settings](img/outbound_requests_section.png)
+
+>**Note:**
+*System hooks* are exempt from this protection because they are set up by admins.
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index 34154b69d2d..7a8b3c75690 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -71,6 +71,16 @@ docker login registry.example.com -u <username> -p <deploy_token>
 Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply 
 pull images from your Container Registry.
 
+### GitLab Deploy Token
+
+> [Introduced][ce-18414] in GitLab 10.8.
+
+There's a special case when it comes to Deploy Tokens, if a user creates one
+named `gitlab-deploy-token`, the name and token of the Deploy Token will be 
+automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER` and 
+`CI_DEPLOY_PASSWORD`, respectively.
+
 [ce-17894]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17894
 [ce-11845]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11845
+[ce-18414]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18414
 [container registry]: ../container_registry.md
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index 442fc978284..2f4ed3493c2 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -38,6 +38,7 @@ do.
 | `/award :emoji:`  | Toggle award for :emoji: |
 | `/board_move ~column`      | Move issue to column on the board |
 | `/duplicate #issue`        | Closes this issue and marks it as a duplicate of another issue |
-| `/move path/to/project`	     | Moves issue to another project |
-| `/tableflip`	             | Append the comment with `(╯°□°)╯︵ ┻━┻` |
-| `/shrug`	                 | Append the comment with `¯\＿(ツ)＿/¯` |
\ No newline at end of file
+| `/move path/to/project`        | Moves issue to another project |
+| `/tableflip`               | Append the comment with `(╯°□°)╯︵ ┻━┻` |
+| `/shrug`                   | Append the comment with `¯\＿(ツ)＿/¯` |
+| <code>/copy_metadata #issue &#124; !merge_request</code> | Copy labels and milestone from other issue or merge request |
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index eb0ac221e30..2c90f4b4413 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -31,7 +31,8 @@ with all their related data and be moved into a new GitLab instance.
 
 | GitLab version   | Import/Export version |
 | ---------------- | --------------------- |
-| 10.4 to current  | 0.2.2                 |
+| 10.8 to current  | 0.2.3                 |
+| 10.4             | 0.2.2                 |
 | 10.3             | 0.2.1                 |
 | 10.0             | 0.2.0                 |
 | 9.4.0            | 0.1.8                 |
diff --git a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md
index 377eee69c11..104ac0cf31b 100644
--- a/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md
+++ b/doc/workflow/lfs/manage_large_binaries_with_git_lfs.md
@@ -244,3 +244,20 @@ GitLab checks files to detect LFS pointers on push. If LFS pointers are detected
 Verify that LFS in installed locally and consider a manual push with `git lfs push --all`.
 
 If you are storing LFS files outside of GitLab you can disable LFS on the project by settting `lfs_enabled: false` with the [projects api](../../api/projects.md#edit-project).
+
+### Hosting LFS objects externally
+
+It is possible to host LFS objects externally by setting a custom LFS url with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`.
+
+Because GitLab verifies the existence of objects referenced by LFS pointers, push will fail when LFS is enabled for the project.
+
+LFS can be disabled for a project by Owners and Masters using the [Project API](../../api/projects.md#edit-project).
+
+```bash
+curl --request PUT \
+  --url https://example.com/api/v4/projects/<PROJECT_ID> \
+  --header 'Private-Token: <YOUR_PRIVATE_TOKEN>' \
+  --data 'lfs_enabled=false'
+```
+
+Note, `<PROJECT_ID>` can also be substituted with a [namespaced path](../../api/README.md#namespaced-path-encoding).