Add latest changes from gitlab-org/gitlab@master

8 files changed, 63 insertions, 28 deletions

diff --git a/doc/administration/monitoring/performance/img/performance_bar.png b/doc/administration/monitoring/performance/img/performance_bar.png
index acad60f863e..73f2ccbe4bb 100644
--- a/doc/administration/monitoring/performance/img/performance_bar.png
+++ b/doc/administration/monitoring/performance/img/performance_bar.png
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index a52b6227e14..caddc87d8c1 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -19,6 +19,7 @@ It allows you to see (from left to right):
 - a link to add a request's details to the performance bar; the request can be
   added by its full URL (authenticated as the current user), or by the value of
   its `X-Request-Id` header
+- a link to download the raw JSON used to generate the Performance Bar reports
 
 On the far right is a request selector that allows you to view the same metrics
 (excluding the page timing and line profiler) for any requests made while the
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index f51c375860b..eb3fc07d7c9 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -321,6 +321,23 @@ pages:
 
 1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
 
+### Using a custom Certificate Authority (CA) with Access Control
+
+When using certificates issued by a custom CA, Access Control on GitLab Pages may fail to work if the custom CA is not recognized.
+
+This usually results in this error:
+`Post /oauth/token: x509: certificate signed by unknown authority`.
+
+For GitLab Pages Access Control with TLS/SSL certs issued by an internal or custom CA:
+
+1. Copy the certificate bundle to `/opt/gitlab/embedded/ssl/certs/` in `.pem` format.
+
+1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
+
+    ```bash
+    sudo gitlab-ctl restart gitlab-pages
+    ```
+
 ## Activate verbose logging for daemon
 
 Verbose logging was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2533) in
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md
index ef94236d711..49f2b61a497 100644
--- a/doc/policy/maintenance.md
+++ b/doc/policy/maintenance.md
@@ -48,8 +48,8 @@ incremental upgrades (and installations) are as simple as possible.
 review process a new change goes through.
 1. Ensuring that tests pass on older release is a considerable challenge in some cases, and as such is very time consuming.
 
-Including new features in patch releases is not possible as that would break [Semantic Versioning].
-Breaking [Semantic Versioning] has the following consequences for users that
+Including new features in patch releases is not possible as that would break [Semantic Versioning](https://semver.org/).
+Breaking [Semantic Versioning](https://semver.org/) has the following consequences for users that
 have to adhere to various internal requirements (e.g. org. compliance, verifying new features and similar):
 
 1. Inability to quickly upgrade to leverage bug fixes included in patch versions.
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 5912fc8e9f9..38ffd07a737 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -63,6 +63,7 @@ Below are the current settings regarding [GitLab CI/CD](../../ci/README.md).
 | -----------             | ----------------- | ------------- |
 | Artifacts maximum size (uncompressed) | 1G                | 100M          |
 | Artifacts [expiry time](../../ci/yaml/README.md#artifactsexpire_in)   | kept forever           | deleted after 30 days unless otherwise specified    |
+| Scheduled Pipeline Cron | `*/5 * * * *` | `*/19 * * * *` |
 
 ## Repository size limit
 
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index c73368fbbd2..ad5a0c2273b 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -34,7 +34,7 @@ namespace.
 
 This service account will be:
 
-- Added to the installed Helm Tiller
+- Added to the installed Helm Tiller.
 - Used by Helm to install and run [GitLab managed applications](index.md#installing-applications).
 
 Helm will also create additional service accounts and other resources for each
@@ -111,6 +111,11 @@ If you don't want to use GitLab Runner in privileged mode, either:
 
 ## Add new cluster
 
+New clusters can be added using GitLab for:
+
+- Google Kubernetes Engine.
+- Amazon Elastic Kubernetes Service.
+
 ### GKE cluster
 
 GitLab supports:
@@ -206,43 +211,30 @@ GitLab supports:
 Before creating your first cluster on Amazon EKS with GitLab's integration,
 make sure the following requirements are met:
 
-- Enable the `create_eks_clusters` feature flag for your GitLab instance.
+- Self-managed GitLab instances have the `create_eks_clusters` feature flag enabled.
 - An [Amazon Web Services](https://aws.amazon.com/) account is set up and you are able to log in.
 - You have permissions to manage IAM resources.
 
-#### Enable the `create_eks_clusters` feature flag **(CORE ONLY)**
-
-NOTE: **Note:**
-If you are running a self-managed instance, EKS cluster creation will not be available
-unless the feature flag `create_eks_clusters` is enabled. This can be done from the Rails console
-by instance administrators.
-
-Use these commands to start the Rails console:
+##### Enable the `create_eks_clusters` feature flag **(CORE ONLY)**
 
-```sh
-# Omnibus GitLab
-gitlab-rails console
+Self-managed instances must have the feature flag `create_eks_clusters` enabled to create
+EKS clusters. To enable EKS cluster creation, ask a GitLab administrator with Rails console access
+to run the following command:
 
-# Installation from source
-cd /home/git/gitlab
-sudo -u git -H bin/rails console RAILS_ENV=production
-```
-
-Then run the following command to enable the feature flag:
-
-```
+```ruby
 Feature.enable(:create_eks_clusters)
 ```
 
-You can also enable the feature flag only for specific projects with:
+To have it enabled for a specific project only, ask a GitLab administrator to run the following
+command using a Rails console:
 
-```
+```ruby
 Feature.enable(:create_eks_clusters, Project.find_by_full_path('my_group/my_project'))
 ```
 
-Run the following command to disable the feature flag:
+To have this feature disabled, ask a GitLab administrator to run the following command:
 
-```
+```ruby
 Feature.disable(:create_eks_clusters)
 ```
 
diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md
index 874a1092b73..d08c8699eba 100644
--- a/doc/user/project/integrations/jira.md
+++ b/doc/user/project/integrations/jira.md
@@ -20,7 +20,7 @@ Here's how the integration responds when you take the following actions in GitLa
 - **Mention a Jira issue ID** in a commit message or MR (merge request).
   - GitLab hyperlinks to the Jira issue.
   - The Jira issue adds an issue link to the commit/MR in GitLab.
-  - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab.
+  - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab, unless this commenting to Jira is [disabled](#disabling-comments-on-jira-issues).
 - **Mention that a commit or MR 'closes', 'resolves', or 'fixes' a Jira issue ID**. When the commit is made on the project's default branch (usually master) or the change is merged to the default branch:
   - GitLab's merge request page displays a note that it "Closed" the Jira issue, with a link to the issue. (Note: Before the merge, an MR will display that it "Closes" the Jira issue.)
   - The Jira issue shows the activity and the Jira issue is closed, or otherwise transitioned.
@@ -95,6 +95,15 @@ with all Jira projects in your Jira instance and you'll see the Jira link on the
 
 ![Jira service page](img/jira_service_page_v12_2.png)
 
+### Disabling comments on Jira issues
+
+When you reference a Jira issue, it will always link back to the source commit/MR in GitLab, however, you can control whether GitLab will also cross-post a comment to the Jira issue. That functionality is enabled by default.
+
+To disable the automated commenting on Jira issues:
+
+1. Open the [Integrations page](project_services.md#accessing-the-project-services) and select **Jira**.
+1. In the **Event Action** section, uncheck **Comment**.
+
 ## Jira issues
 
 By now you should have [configured Jira](#configuring-jira) and enabled the
diff --git a/doc/user/project/repository/repository_mirroring.md b/doc/user/project/repository/repository_mirroring.md
index a682983ab83..7d49aecb603 100644
--- a/doc/user/project/repository/repository_mirroring.md
+++ b/doc/user/project/repository/repository_mirroring.md
@@ -143,6 +143,7 @@ Changes pushed to the upstream repository will be pulled into the GitLab reposit
 CAUTION: **Caution:**
 If you do manually update a branch in the GitLab repository, the branch will become diverged from
 upstream and GitLab will no longer automatically update this branch to prevent any changes from being lost.
+Also note that deleted branches and tags in the upstream repository will not be reflected in the GitLab repository.
 
 ### How it works
 
@@ -247,6 +248,10 @@ If you need to change the key at any time, you can remove and re-add the mirror
 to generate a new key. You'll have to update the other repository with the new
 key to keep the mirror running.
 
+NOTE: **Note:**
+The generated keys are stored in the GitLab database, not in the filesystem. Therefore,
+SSH public key authentication for mirrors cannot be used in a pre-receive hook.
+
 ### Overwrite diverged branches **(STARTER)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/4559) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.6.
@@ -362,6 +367,7 @@ proxy_push()
       branch=$(expr "$refname" : "refs/heads/\(.*\)")
 
       if [ "$whitelisted" = "$branch" ]; then
+        unset GIT_QUARANTINE_PATH # handle https://git-scm.com/docs/git-receive-pack#_quarantine_environment
         error="$(git push --quiet $TARGET_REPO $NEWREV:$REFNAME 2>&1)"
         fail=$?
 
@@ -396,6 +402,15 @@ else
 fi
 ```
 
+Note that this sample has a few limitations:
+
+- This example may not work verbatim for your use case and might need modification.
+  - It does not regard different types of authentication mechanisms for the mirror.
+  - It does not work with forced updates (rewriting history).
+  - Only branches that match the `whitelisted` patterns will be proxy pushed.
+- The script circumvents the git hook quarantine environment because the update of `$TARGET_REPO`
+  is seen as a ref update and git will complain about it.
+
 ### Mirroring with Perforce Helix via Git Fusion **(STARTER)**
 
 CAUTION: **Warning:**