Add latest changes from gitlab-org/gitlab@master

9 files changed, 142 insertions, 121 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 6388fe34135..d5e141459b6 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -107,7 +107,7 @@ recorded:
 - Started/stopped user impersonation
 
 It is possible to filter particular actions by choosing an audit data type from
-the filter drop-down. You can further filter by specific group, project or user
+the filter dropdown box. You can further filter by specific group, project or user
 (for authentication events).
 
 ![audit log](img/audit_log.png)
diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
new file mode 100644
index 00000000000..5ef739a4289
--- /dev/null
+++ b/doc/administration/file_hooks.md
@@ -0,0 +1,116 @@
+# File hooks
+
+> Introduced in GitLab 10.6.
+> Until 12.8 the feature name was Plugins.
+
+With custom file hooks, GitLab administrators can introduce custom integrations
+without modifying GitLab's source code.
+
+NOTE: **Note:**
+Instead of writing and supporting your own file hook you can make changes
+directly to the GitLab source code and contribute back upstream. This way we can
+ensure functionality is preserved across versions and covered by tests.
+
+NOTE: **Note:**
+File hooks must be configured on the filesystem of the GitLab server. Only GitLab
+server administrators will be able to complete these tasks. Explore
+[system hooks] or [webhooks] as an option if you do not have filesystem access.
+
+A file hook will run on each event so it's up to you to filter events or projects
+within a file hook code. You can have as many file hooks as you want. Each file hook will
+be triggered by GitLab asynchronously in case of an event. For a list of events
+see the [system hooks] documentation.
+
+## Setup
+
+The file hooks must be placed directly into the `plugins` directory, subdirectories
+will be ignored. There is an
+[`example` directory inside `plugins`](https://gitlab.com/gitlab-org/gitlab/tree/master/plugins/examples)
+where you can find some basic examples.
+
+Follow the steps below to set up a custom hook:
+
+1. On the GitLab server, navigate to the plugin directory.
+   For an installation from source the path is usually
+   `/home/git/gitlab/plugins/`. For Omnibus installs the path is
+   usually `/opt/gitlab/embedded/service/gitlab-rails/plugins`.
+
+    For [highly available] configurations, your hook file should exist on each
+    application server.
+
+1. Inside the `plugins` directory, create a file with a name of your choice,
+   without spaces or special characters.
+1. Make the hook file executable and make sure it's owned by the Git user.
+1. Write the code to make the file hook function as expected. That can be
+   in any language, and ensure the 'shebang' at the top properly reflects the
+   language type. For example, if the script is in Ruby the shebang will
+   probably be `#!/usr/bin/env ruby`.
+1. The data to the file hook will be provided as JSON on STDIN. It will be exactly
+   same as for [system hooks]
+
+That's it! Assuming the file hook code is properly implemented, the hook will fire
+as appropriate. The file hooks file list is updated for each event, there is no
+need to restart GitLab to apply a new file hook.
+
+If a file hook executes with non-zero exit code or GitLab fails to execute it, a
+message will be logged to:
+
+- `gitlab-rails/plugin.log` in an Omnibus installation.
+- `log/plugin.log` in a source installation.
+
+## Creating file hooks
+
+Below is an example that will only response on the event `project_create` and
+will inform the admins from the GitLab instance that a new project has been created.
+
+```ruby
+# By using the embedded ruby version we eliminate the possibility that our chosen language
+# would be unavailable from
+#!/opt/gitlab/embedded/bin/ruby
+require 'json'
+require 'mail'
+
+# The incoming variables are in JSON format so we need to parse it first.
+ARGS = JSON.parse(STDIN.read)
+
+# We only want to trigger this file hook on the event project_create
+return unless ARGS['event_name'] == 'project_create'
+
+# We will inform our admins of our gitlab instance that a new project is created
+Mail.deliver do
+  from    'info@gitlab_instance.com'
+  to      'admin@gitlab_instance.com'
+  subject "new project " + ARGS['name']
+  body    ARGS['owner_name'] + 'created project ' + ARGS['name']
+end
+```
+
+## Validation
+
+Writing your own file hook can be tricky and it's easier if you can check it
+without altering the system. A rake task is provided so that you can use it
+in a staging environment to test your file hook before using it in production.
+The rake task will use a sample data and execute each of file hook. The output
+should be enough to determine if the system sees your file hook and if it was
+executed without errors.
+
+```bash
+# Omnibus installations
+sudo gitlab-rake file_hooks:validate
+
+# Installations from source
+cd /home/git/gitlab
+bundle exec rake file_hooks:validate RAILS_ENV=production
+```
+
+Example of output:
+
+```
+Validating file hooks from /plugins directory
+* /home/git/gitlab/plugins/save_to_file.clj succeed (zero exit code)
+* /home/git/gitlab/plugins/save_to_file.rb failure (non-zero exit code)
+```
+
+[system hooks]: ../system_hooks/system_hooks.md
+[webhooks]: ../user/project/integrations/webhooks.md
+[highly available]: ./high_availability/README.md
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index eb7a2d791c1..62bacf9791e 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -245,7 +245,7 @@ To add a Prometheus dashboard for a single server GitLab setup:
 
 1. Create a new data source in Grafana.
 1. Name your data source i.e GitLab.
-1. Select `Prometheus` in the type drop down.
+1. Select `Prometheus` in the type dropdown box.
 1. Add your Prometheus listen address as the URL and set access to `Browser`.
 1. Set the HTTP method to `GET`.
 1. Save & Test your configuration to verify that it works.
diff --git a/doc/administration/plugins.md b/doc/administration/plugins.md
index 6e4e445ef8f..dbb733b9b19 100644
--- a/doc/administration/plugins.md
+++ b/doc/administration/plugins.md
@@ -1,115 +1,5 @@
-# GitLab Plugin system
+---
+redirect_to: 'file_hooks.md'
+---
 
-> Introduced in GitLab 10.6.
-
-With custom plugins, GitLab administrators can introduce custom integrations
-without modifying GitLab's source code.
-
-NOTE: **Note:**
-Instead of writing and supporting your own plugin you can make changes
-directly to the GitLab source code and contribute back upstream. This way we can
-ensure functionality is preserved across versions and covered by tests.
-
-NOTE: **Note:**
-Plugins must be configured on the filesystem of the GitLab server. Only GitLab
-server administrators will be able to complete these tasks. Explore
-[system hooks] or [webhooks] as an option if you do not have filesystem access.
-
-A plugin will run on each event so it's up to you to filter events or projects
-within a plugin code. You can have as many plugins as you want. Each plugin will
-be triggered by GitLab asynchronously in case of an event. For a list of events
-see the [system hooks] documentation.
-
-## Setup
-
-The plugins must be placed directly into the `plugins` directory, subdirectories
-will be ignored. There is an
-[`example` directory inside `plugins`](https://gitlab.com/gitlab-org/gitlab/tree/master/plugins/examples)
-where you can find some basic examples.
-
-Follow the steps below to set up a custom hook:
-
-1. On the GitLab server, navigate to the plugin directory.
-   For an installation from source the path is usually
-   `/home/git/gitlab/plugins/`. For Omnibus installs the path is
-   usually `/opt/gitlab/embedded/service/gitlab-rails/plugins`.
-
-    For [highly available] configurations, your hook file should exist on each
-    application server.
-
-1. Inside the `plugins` directory, create a file with a name of your choice,
-   without spaces or special characters.
-1. Make the hook file executable and make sure it's owned by the Git user.
-1. Write the code to make the plugin function as expected. That can be
-   in any language, and ensure the 'shebang' at the top properly reflects the
-   language type. For example, if the script is in Ruby the shebang will
-   probably be `#!/usr/bin/env ruby`.
-1. The data to the plugin will be provided as JSON on STDIN. It will be exactly
-   same as for [system hooks]
-
-That's it! Assuming the plugin code is properly implemented, the hook will fire
-as appropriate. The plugins file list is updated for each event, there is no
-need to restart GitLab to apply a new plugin.
-
-If a plugin executes with non-zero exit code or GitLab fails to execute it, a
-message will be logged to:
-
-- `gitlab-rails/plugin.log` in an Omnibus installation.
-- `log/plugin.log` in a source installation.
-
-## Creating plugins
-
-Below is an example that will only response on the event `project_create` and
-will inform the admins from the GitLab instance that a new project has been created.
-
-```ruby
-# By using the embedded ruby version we eliminate the possibility that our chosen language
-# would be unavailable from
-#!/opt/gitlab/embedded/bin/ruby
-require 'json'
-require 'mail'
-
-# The incoming variables are in JSON format so we need to parse it first.
-ARGS = JSON.parse(STDIN.read)
-
-# We only want to trigger this plugin on the event project_create
-return unless ARGS['event_name'] == 'project_create'
-
-# We will inform our admins of our gitlab instance that a new project is created
-Mail.deliver do
-  from    'info@gitlab_instance.com'
-  to      'admin@gitlab_instance.com'
-  subject "new project " + ARGS['name']
-  body    ARGS['owner_name'] + 'created project ' + ARGS['name']
-end
-```
-
-## Validation
-
-Writing your own plugin can be tricky and it's easier if you can check it
-without altering the system. A rake task is provided so that you can use it
-in a staging environment to test your plugin before using it in production.
-The rake task will use a sample data and execute each of plugin. The output
-should be enough to determine if the system sees your plugin and if it was
-executed without errors.
-
-```bash
-# Omnibus installations
-sudo gitlab-rake plugins:validate
-
-# Installations from source
-cd /home/git/gitlab
-bundle exec rake plugins:validate RAILS_ENV=production
-```
-
-Example of output:
-
-```
-Validating plugins from /plugins directory
-* /home/git/gitlab/plugins/save_to_file.clj succeed (zero exit code)
-* /home/git/gitlab/plugins/save_to_file.rb failure (non-zero exit code)
-```
-
-[system hooks]: ../system_hooks/system_hooks.md
-[webhooks]: ../user/project/integrations/webhooks.md
-[highly available]: ./high_availability/README.md
+This document was moved to [File Hooks](file_hooks.md), after the Plugins feature was renamed to File Hooks.
diff --git a/doc/ci/enable_or_disable_ci.md b/doc/ci/enable_or_disable_ci.md
index 44815ff7af4..7c7640e23c3 100644
--- a/doc/ci/enable_or_disable_ci.md
+++ b/doc/ci/enable_or_disable_ci.md
@@ -44,7 +44,7 @@ To enable or disable GitLab CI/CD Pipelines in your project:
 
 - **Private**: Only project members can access pipelines.
 - **Internal** or **Public**: Pipelines can be set to either **Only Project Members**
-  or **Everyone With Access** via the drop-down box.
+  or **Everyone With Access** via the dropdown box.
 
 Press **Save changes** for the settings to take effect.
 
diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md
index 8165d3edabb..610b21234b1 100644
--- a/doc/install/aws/index.md
+++ b/doc/install/aws/index.md
@@ -244,7 +244,7 @@ Once the database is created, connect to your new RDS instance to verify access
 and to install a required extension.
 
 You can find the host or endpoint by selecting the instance you just created and
-after the details drop down you'll find it labeled as 'Endpoint'. Do not to
+after the details dropdown menu you'll find it labeled as 'Endpoint'. Do not to
 include the colon and port number:
 
 ```sh
diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md
index c789467175a..5baaec79048 100644
--- a/doc/install/azure/index.md
+++ b/doc/install/azure/index.md
@@ -226,7 +226,7 @@ connections:
 ![Azure - Add inbound security rules - HTTP](img/azure-add-inbound-sec-rule-http.png)
 
 1. Enter **"HTTP"** in the `Name` field
-1. Select **HTTP** from the options in the `Service` drop-down
+1. Select **HTTP** from the options in the `Service` dropdown list
 1. Make sure the `Action` is set to **Allow**
 1. Click **"OK"**
 
@@ -238,7 +238,7 @@ accept [SSH] connections:
 ![Azure - Add inbound security rules - SSH](img/azure-add-inbound-sec-rule-ssh.png)
 
 1. Enter **"SSH"** in the `Name` field
-1. Select **SSH** from the options in the `Service` drop-down
+1. Select **SSH** from the options in the `Service` dropdown list
 1. Make sure the `Action` is set to **Allow**
 1. Click **"OK"**
 
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 08242b3c65b..eb726ee2ed7 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -269,6 +269,15 @@ it highlighted:
     }
   ],
   "remediations": [
+    {
+      "fixes": [
+        {
+          "cve": "debian:9:apt:CVE-2019-3462"
+        }
+      ],
+      "summary": "Upgrade apt from 1.4.8 to 1.4.9",
+      "diff": "YXB0LWdldCB1cGRhdGUgJiYgYXB0LWdldCB1cGdyYWRlIC15IGFwdA=="
+    }
   ]
 }
 ```
@@ -305,7 +314,11 @@ the report JSON unless stated otherwise. Presence of optional fields depends on
 | `vulnerabilities[].links`                            | An array of references to external documentation pieces or articles that describe the vulnerability further. Optional.                                                                                                                                                                                                                                                                     |
 | `vulnerabilities[].links[].name`                     | Name of the vulnerability details link. Optional.                                                                                                                                                                                                                                                                                                                                          |
 | `vulnerabilities[].links[].url`                      | URL of the vulnerability details document. Optional.                                                                                                                                                                                                                                                                                                                                       |
-| `remediations`                                       | Not supported yet.                                                                                                                                                                                                                                                                                                                                                                         |
+| `remediations`                                       | An array of objects containing information on cured vulnerabilities along with patch diffs to apply. Empty if no remediations provided by an underlying analyzer.                                                                                                                                                                                                                          |
+| `remediations[].fixes`                               | An array of strings that represent references to vulnerabilities fixed by this particular remediation.                                                                                                                                                                                                                                                                                     |
+| `remediations[].fixes[].cve`                         | A string value that describes a fixed vulnerability occurrence in the same format as `vulnerabilities[].cve`.                                                                                                                                                                                                                                                                              |
+| `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).                                                                                                                                                                                                                                                                |
 
 ## Troubleshooting
 
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index 594f73dbfbe..83fbbd04739 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -71,6 +71,8 @@ Designs cannot be added if the issue has been moved, or its
 ## Viewing designs
 
 Images on the Design Management page can be enlarged by clicking on them.
+You can navigate through designs by clicking on the navigation buttons on the
+top-right corner or with <kbd>Left</kbd>/<kbd>Right</kbd> keyboard buttons.
 
 The number of comments on a design — if any — is listed to the right
 of the design filename. Clicking on this number enlarges the design