Add latest changes from gitlab-org/gitlab@master

.gitlab/ci/review.gitlab-ci.yml

@@ -94,10 +94,7 @@ schedule:review-build-cng:
   variables:
     HOST_SUFFIX: "${CI_ENVIRONMENT_SLUG}"
     DOMAIN: "-${CI_ENVIRONMENT_SLUG}.${REVIEW_APPS_DOMAIN}"
-    # v2.3.7 + some stability improvements not yet released:
-    # - sidekiq readinessProbe should be `pgrep -f sidekiq`: https://gitlab.com/gitlab-org/charts/gitlab/merge_requests/991
-    # - Allows livenessProbe and readinessProbe to be configured for unicorn: https://gitlab.com/gitlab-org/charts/gitlab/merge_requests/985
-    GITLAB_HELM_CHART_REF: "df7c52dc69df441909880b8f2fd15e938cdb2047"
+    GITLAB_HELM_CHART_REF: "v2.4.4"
     GITLAB_EDITION: "ce"
   environment:
     name: review/${CI_COMMIT_REF_NAME}

app/controllers/concerns/metrics_dashboard.rb

@@ -3,21 +3,24 @@
 # Provides an action which fetches a metrics dashboard according
 # to the parameters specified by the controller.
 module MetricsDashboard
+  include RenderServiceResults
   extend ActiveSupport::Concern
   def metrics_dashboard
     result = dashboard_finder.find(
       project_for_dashboard,
       current_user,
-      metrics_dashboard_params
+      metrics_dashboard_params.to_h.symbolize_keys
     )
-    if include_all_dashboards?
+    if include_all_dashboards? && result
       result[:all_dashboards] = dashboard_finder.find_all_paths(project_for_dashboard)
     end
     respond_to do |format|
-      if result[:status] == :success
+      if result.nil?
+        format.json { continue_polling_response }
+      elsif result[:status] == :success
         format.json { render dashboard_success_response(result) }
       else
         format.json { render dashboard_error_response(result) }
@@ -56,7 +59,7 @@ module MetricsDashboard
   def dashboard_error_response(result)
     {
-      status: result[:http_status],
+      status: result[:http_status] || :bad_request,
       json: result.slice(:all_dashboards, :message, :status)
     }
   end

app/controllers/projects/environments_controller.rb

@@ -199,8 +199,7 @@ class Projects::EnvironmentsController < Projects::ApplicationController
   def metrics_dashboard_params
     params
-      .permit(:embedded, :group, :title, :y_label)
-      .to_h.symbolize_keys
+      .permit(:embedded, :group, :title, :y_label, :dashboard_path, :environment)
       .merge(dashboard_path: params[:dashboard], environment: environment)
   end

app/controllers/projects/grafana_api_controller.rb

@@ -2,6 +2,9 @@
 class Projects::GrafanaApiController < Projects::ApplicationController
   include RenderServiceResults
+  include MetricsDashboard
+
+  before_action :validate_feature_enabled!, only: [:metrics_dashboard]
   def proxy
     result = ::Grafana::ProxyService.new(
@@ -19,6 +22,14 @@ class Projects::GrafanaApiController < Projects::ApplicationController
   private
+  def metrics_dashboard_params
+    params.permit(:embedded, :grafana_url)
+  end
+
+  def validate_feature_enabled!
+    render_403 unless Feature.enabled?(:gfm_grafana_integration)
+  end
+
   def query_params
     params.permit(:query, :start, :end, :step)
   end

app/helpers/search_helper.rb

 # frozen_string_literal: true
 module SearchHelper
+  SEARCH_PERMITTED_PARAMS = [:search, :scope, :project_id, :group_id, :repository_ref, :snippets].freeze
+
   def search_autocomplete_opts(term)
     return unless current_user
@@ -200,7 +202,7 @@ module SearchHelper
     search_params = params
       .merge(search)
       .merge({ scope: scope })
-      .permit(:search, :scope, :project_id, :group_id, :repository_ref, :snippets)
+      .permit(SEARCH_PERMITTED_PARAMS)
     if @scope == scope
       li_class = 'active'

app/helpers/tree_helper.rb

@@ -197,9 +197,7 @@ module TreeHelper
   end
   def directory_download_links(project, ref, archive_prefix)
-    formats = ['zip', 'tar.gz', 'tar.bz2', 'tar']
-
-    formats.map do |fmt|
+    Gitlab::Workhorse::ARCHIVE_FORMATS.map do |fmt|
       {
         text: fmt,
         path: project_archive_path(project, id: tree_join(ref, archive_prefix), format: fmt)

app/models/releases/source.rb

@@ -6,11 +6,9 @@ module Releases
     attr_accessor :project, :tag_name, :format
-    FORMATS = %w(zip tar.gz tar.bz2 tar).freeze
-
     class << self
       def all(project, tag_name)
-        Releases::Source::FORMATS.map do |format|
+        Gitlab::Workhorse::ARCHIVE_FORMATS.map do |format|
           Releases::Source.new(project: project,
                                tag_name: tag_name,
                                format: format)

app/services/groups/transfer_service.rb

@@ -13,7 +13,7 @@ module Groups
     TransferError = Class.new(StandardError)
-    attr_reader :error
+    attr_reader :error, :new_parent_group
     def initialize(group, user, params = {})
       super
@@ -115,3 +115,5 @@ module Groups
     end
   end
 end
+
+Groups::TransferService.prepend_if_ee('EE::Groups::TransferService')

app/services/projects/transfer_service.rb

@@ -13,6 +13,8 @@ module Projects
     include Gitlab::ShellAdapter
     TransferError = Class.new(StandardError)
+    attr_reader :new_namespace
+
     def execute(new_namespace)
       @new_namespace = new_namespace

app/views/projects/buttons/_download_links.html.haml

-- formats = [['zip', 'btn-primary'], ['tar.gz'], ['tar.bz2'], ['tar']]
-
 .btn-group.ml-0.w-100
-  - formats.each do |(fmt, extra_class)|
+  - Gitlab::Workhorse::ARCHIVE_FORMATS.each_with_index do |fmt, index|
     - archive_path = project_archive_path(project, id: tree_join(ref, archive_prefix), path: path, format: fmt)
-    = link_to fmt, external_storage_url_or_path(archive_path), rel: 'nofollow', download: '', class: "btn btn-xs #{extra_class}"
+    = link_to fmt, external_storage_url_or_path(archive_path), rel: 'nofollow', download: '', class: "btn btn-xs #{"btn-primary" if index == 0}"

app/views/search/_results.html.haml

 - if @search_objects.to_a.empty?
   = render partial: "search/results/empty"
   = render_if_exists 'shared/promotions/promote_advanced_search'
+  = render_if_exists 'search/form_revert_to_basic'
 - else
   .row-content-block.d-md-flex.text-left.align-items-center
     - unless @search_objects.is_a?(Kaminari::PaginatableWithoutCount)

changelogs/unreleased/sh-use-rails-redis-store.yml

+---
+title: Use Rails 5.2 Redis caching store
+merge_request: 19202
+author:
+type: other

config/application.rb

@@ -247,7 +247,10 @@ module Gitlab
     end
     # Use caching across all environments
+    # Full list of options:
+    # https://api.rubyonrails.org/classes/ActiveSupport/Cache/RedisCacheStore.html#method-c-new
     caching_config_hash = Gitlab::Redis::Cache.params
+    caching_config_hash[:compress] = false
     caching_config_hash[:namespace] = Gitlab::Redis::Cache::CACHE_NAMESPACE
     caching_config_hash[:expires_in] = 2.weeks # Cache should not grow forever
     if Sidekiq.server? # threaded context
@@ -255,7 +258,7 @@ module Gitlab
       caching_config_hash[:pool_timeout] = 1
     end
-    config.cache_store = :redis_store, caching_config_hash
+    config.cache_store = :redis_cache_store, caching_config_hash
     config.active_job.queue_adapter = :sidekiq

config/routes/project.rb

@@ -187,9 +187,10 @@ constraints(::Constraints::ProjectUrlConstrainer.new) do
         resource :import, only: [:new, :create, :show]
         resource :avatar, only: [:show, :destroy]
-        get 'grafana/proxy/:datasource_id/*proxy_path',
-            to: 'grafana_api#proxy',
-            as: :grafana_api
+        scope :grafana, as: :grafana_api do
+          get 'proxy/:datasource_id/*proxy_path', to: 'grafana_api#proxy'
+          get :metrics_dashboard, to: 'grafana_api#metrics_dashboard'
+        end
       end
       # End of the /-/ scope.

doc/administration/gitaly/index.md

@@ -328,6 +328,8 @@ When you tail the Gitaly logs on your Gitaly server you should see requests
 coming in. One sure way to trigger a Gitaly request is to clone a repository
 from your GitLab server over HTTP.
+DANGER: **Danger:** If you have [custom server-side Git hooks](../custom_hooks.md#custom-server-side-git-hooks) configured, either per repository or globally, you must move these to the Gitaly node. If you have multiple Gitaly nodes, copy your custom hook(s) to all nodes.
+
 ### Disabling the Gitaly service in a cluster environment
 If you are running Gitaly [as a remote

doc/integration/elasticsearch.md

@@ -583,3 +583,12 @@ Here are some common pitfalls and how to overcome them:
   AWS has [fixed limits](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
   for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
   the underlying instance.
+
+### Reverting to basic search
+
+Sometimes there may be issues with your Elasticsearch index data and as such
+GitLab will allow you to revert to "basic search" when there are no search
+results and assuming that basic search is supported in that scope. This "basic
+search" will behave as though you don't have Elasticsearch enabled at all for
+your instance and search using other data sources (ie. Postgres data and Git
+data).

doc/topics/autodevops/index.md

@@ -95,58 +95,85 @@ Auto DevOps.
 To make full use of Auto DevOps, you will need:
+- **Kubernetes** (for Auto Review Apps, Auto Deploy, and Auto Monitoring)
+
+  To enable deployments, you will need:
+
+  1. A [Kubernetes 1.5+ cluster](../../user/project/clusters/index.md) for the project. The easiest
+     way is to add a [new GKE cluster using the GitLab UI](../../user/project/clusters/add_remove_clusters.md#add-new-gke-cluster).
+  1. NGINX Ingress. You can deploy it to your Kubernetes cluster by installing
+     the [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
+     once you have configured GitLab's Kubernetes integration in the previous step.
+
+     Alternatively, you can use the
+     [`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
+     Helm chart to install Ingress manually.
+
+     NOTE: **Note:**
+     If you are using your own Ingress instead of the one provided by GitLab's managed
+     apps, ensure you are running at least version 0.9.0 of NGINX Ingress and
+     [enable Prometheus metrics](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/customization/custom-vts-metrics-prometheus/nginx-vts-metrics-conf.yaml)
+     in order for the response metrics to appear. You will also have to
+     [annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
+     the NGINX Ingress deployment to be scraped by Prometheus using
+     `prometheus.io/scrape: "true"` and `prometheus.io/port: "10254"`.
+
+- **Base domain** (for Auto Review Apps, Auto Deploy, and Auto Monitoring)
+
+  You will need a domain configured with wildcard DNS which is going to be used
+  by all of your Auto DevOps applications. If you're using the
+  [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
+  the URL endpoint will be automatically configured for you.
+
+  You will then need to [specify the Auto DevOps base domain](#auto-devops-base-domain).
+
 - **GitLab Runner** (for all stages)
   Your Runner needs to be configured to be able to run Docker. Generally this
   means using either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
   or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with
   [privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
-
   The Runners do not need to be installed in the Kubernetes cluster, but the
   Kubernetes executor is easy to use and is automatically autoscaling.
   Docker-based Runners can be configured to autoscale as well, using [Docker
   Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
+  If you have configured GitLab's Kubernetes integration in the first step, you
+  can deploy it to your cluster by installing the
+  [GitLab-managed app for GitLab Runner](../../user/clusters/applications.md#gitlab-runner).
+
   Runners should be registered as [shared Runners](../../ci/runners/README.md#registering-a-shared-runner)
   for the entire GitLab instance, or [specific Runners](../../ci/runners/README.md#registering-a-specific-runner)
-  that are assigned to specific projects.
-- **Base domain** (for Auto Review Apps and Auto Deploy)
-
-  You will need a domain configured with wildcard DNS which is going to be used
-  by all of your Auto DevOps applications.
-  Read the [specifics](#auto-devops-base-domain).
-- **Kubernetes** (for Auto Review Apps, Auto Deploy, and Auto Monitoring)
-
-  To enable deployments, you will need:
-
-  - Kubernetes 1.5+.
-  - A [Kubernetes cluster][kubernetes-clusters] for the project.
-  - A load balancer. You can use NGINX Ingress by deploying it to your
-    Kubernetes cluster by either:
-    - Using the [`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress) Helm chart.
-    - Installing the Ingress [GitLab Managed App](../../user/clusters/applications.md#ingress).
+  that are assigned to specific projects (the default if you have installed the
+  GitLab Runner managed application).
 - **Prometheus** (for Auto Monitoring)
-  To enable Auto Monitoring, you
-  will need Prometheus installed somewhere (inside or outside your cluster) and
-  configured to scrape your Kubernetes cluster. To get response metrics
-  (in addition to system metrics), you need to
-  [configure Prometheus to monitor NGINX](../../user/project/integrations/prometheus_library/nginx_ingress.md#configuring-nginx-ingress-monitoring).
+  To enable Auto Monitoring, you will need Prometheus installed somewhere
+  (inside or outside your cluster) and configured to scrape your Kubernetes cluster.
+  If you have configured GitLab's Kubernetes integration, you can deploy it to
+  your cluster by installing the
+  [GitLab-managed app for Prometheus](../../user/clusters/applications.md#prometheus).
   The [Prometheus service](../../user/project/integrations/prometheus.md)
-  integration needs to be enabled for the project, or enabled as a
+  integration needs to be enabled for the project (or enabled as a
   [default service template](../../user/project/integrations/services_templates.md)
-  for the entire GitLab installation.
+  for the entire GitLab installation).
+
+  To get response metrics (in addition to system metrics), you need to
+  [configure Prometheus to monitor NGINX](../../user/project/integrations/prometheus_library/nginx_ingress.md#configuring-nginx-ingress-monitoring).
 If you do not have Kubernetes or Prometheus installed, then Auto Review Apps,
 Auto Deploy, and Auto Monitoring will be silently skipped.
+One all requirements are met, you can go ahead and [enable Auto DevOps](#enablingdisabling-auto-devops).
+
 ## Auto DevOps base domain
-The Auto DevOps base domain is required if you want to make use of [Auto
-Review Apps](#auto-review-apps) and [Auto Deploy](#auto-deploy). It can be defined
-in any of the following places:
+The Auto DevOps base domain is required if you want to make use of
+[Auto Review Apps](#auto-review-apps), [Auto Deploy](#auto-deploy), and
+[Auto Monitoring](#auto-monitoring). It can be defined in any of the following
+places:
 - either under the cluster's settings, whether for [projects](../../user/project/clusters/index.md#base-domain) or [groups](../../user/group/clusters/index.md#base-domain)
 - or in instance-wide settings in the **admin area > Settings** under the "Continuous Integration and Delivery" section
@@ -156,9 +183,15 @@ in any of the following places:
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
 as other environment [variables](../../ci/variables/README.md#priority-of-environment-variables).
-NOTE: **Note**
-`AUTO_DEVOPS_DOMAIN` environment variable is deprecated and
-[is scheduled to be removed](https://gitlab.com/gitlab-org/gitlab-foss/issues/56959).
+TIP: **Tip:**
+If you're using the [GitLab managed app for Ingress](../../user/clusters/applications.md#ingress),
+the URL endpoint should be automatically configured for you. All you have to do
+is use its value for the `KUBE_INGRESS_BASE_DOMAIN` variable.
+
+NOTE: **Note:**
+`AUTO_DEVOPS_DOMAIN` was [deprecated in GitLab 11.8](https://gitlab.com/gitlab-org/gitlab-foss/issues/52363)
+and replaced with `KUBE_INGRESS_BASE_DOMAIN`. It was removed in
+[GitLab 12.0](https://gitlab.com/gitlab-org/gitlab-foss/issues/56959).
 A wildcard DNS A record matching the base domain(s) is required, for example,
 given a base domain of `example.com`, you'd need a DNS entry like:
@@ -179,77 +212,28 @@ Auto DevOps base domain to `1.2.3.4.nip.io`.
 Once set up, all requests will hit the load balancer, which in turn will route
 them to the Kubernetes pods that run your application(s).
-NOTE: **Note:**
-From GitLab 11.8, `KUBE_INGRESS_BASE_DOMAIN` replaces `AUTO_DEVOPS_DOMAIN`.
-Support for `AUTO_DEVOPS_DOMAIN` was [removed in GitLab
-12.0](https://gitlab.com/gitlab-org/gitlab-foss/issues/56959).
-
-## Using multiple Kubernetes clusters **(PREMIUM)**
-
-When using Auto DevOps, you may want to deploy different environments to
-different Kubernetes clusters. This is possible due to the 1:1 connection that
-[exists between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters-premium).
-
-In the [Auto DevOps template] (used behind the scenes by Auto DevOps), there
-are currently 3 defined environment names that you need to know:
-
-- `review/` (every environment starting with `review/`)
-- `staging`
-- `production`
-
-Those environments are tied to jobs that use [Auto Deploy](#auto-deploy), so
-except for the environment scope, they would also need to have a different
-domain they would be deployed to. This is why you need to define a separate
-`KUBE_INGRESS_BASE_DOMAIN` variable for all the above
-[based on the environment](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables).
-
-The following table is an example of how the three different clusters would
-be configured.
-
-| Cluster name | Cluster environment scope | `KUBE_INGRESS_BASE_DOMAIN` variable value | Variable environment scope | Notes |
-|--------------|---------------------------|-------------------------------------------|----------------------------|---|
-| review       | `review/*`                | `review.example.com`                      | `review/*`                 | The review cluster which will run all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, which means it will be used by every environment name starting with `review/`. |
-| staging      | `staging`                 | `staging.example.com`                     | `staging`                  | (Optional) The staging cluster which will run the deployments of the staging environments. You need to [enable it first](#deploy-policy-for-staging-and-production-environments). |
-| production   | `production`              | `example.com`                             | `production`               | The production cluster which will run the deployments of the production environment. You can use [incremental rollouts](#incremental-rollout-to-production-premium). |
-
-To add a different cluster for each environment:
-
-1. Navigate to your project's **Operations > Kubernetes** and create the Kubernetes clusters
-   with their respective environment scope as described from the table above.
-
-   ![Auto DevOps multiple clusters](img/autodevops_multiple_clusters.png)
-
-1. After the clusters are created, navigate to each one and install Helm Tiller
-   and Ingress. Wait for the Ingress IP address to be assigned.
-1. Make sure you have [configured your DNS](#auto-devops-base-domain) with the
-   specified Auto DevOps domains.
-1. Navigate to each cluster's page, through **Operations > Kubernetes**,
-   and add the domain based on its Ingress IP address.
-
-Now that all is configured, you can test your setup by creating a merge request
-and verifying that your app is deployed as a review app in the Kubernetes
-cluster with the `review/*` environment scope. Similarly, you can check the
-other environments.
-
 ## Enabling/Disabling Auto DevOps
-When first using Auto Devops, review the [requirements](#requirements) to ensure all necessary components to make
+When first using Auto DevOps, review the [requirements](#requirements) to ensure all necessary components to make
 full use of Auto DevOps are available. If this is your fist time, we recommend you follow the
 [quick start guide](quick_start_guide.md).
 GitLab.com users can enable/disable Auto DevOps at the project-level only. Self-managed users
 can enable/disable Auto DevOps at the project-level, group-level or instance-level.
-### At the instance level (Administrators only)
-Even when disabled at the instance level, group owners and project maintainers can still enable
-Auto DevOps at the group and project level, respectively.
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
-1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**.
-1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps.
+### At the project level
+If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it.
+1. Go to your project's **Settings > CI/CD > Auto DevOps**.
+1. Toggle the **Default to Auto DevOps pipeline** checkbox (checked to enable, unchecked to disable)
+1. When enabling, it's optional but recommended to add in the [base domain](#auto-devops-base-domain)
+   that will be used by Auto DevOps to [deploy your application](#auto-deploy)
+   and choose the [deployment strategy](#deployment-strategy).
 1. Click **Save changes** for the changes to take effect.
+When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch.
+
 ### At the group level
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/52447) in GitLab 11.10.
@@ -266,19 +250,16 @@ When enabling or disabling Auto DevOps at group-level, group configuration will
 the subgroups and projects inside that group, unless Auto DevOps is specifically enabled or disabled on
 the subgroup or project.
-### At the project level
-If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it.
-1. Go to your project's **Settings > CI/CD > Auto DevOps**.
-1. Toggle the **Default to Auto DevOps pipeline** checkbox (checked to enable, unchecked to disable)
-1. When enabling, it's optional but recommended to add in the [base domain](#auto-devops-base-domain)
-   that will be used by Auto DevOps to [deploy your application](#auto-deploy)
-   and choose the [deployment strategy](#deployment-strategy).
+### At the instance level (Administrators only)
+Even when disabled at the instance level, group owners and project maintainers can still enable
+Auto DevOps at the group and project level, respectively.
+1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
+1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**.
+1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps.
 1. Click **Save changes** for the changes to take effect.
-When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch.
-
 ### Enable for a percentage of projects
 There is also a feature flag to enable Auto DevOps by default to your chosen percentage of projects.
@@ -310,6 +291,53 @@ The available options are:
   - `master` branch is directly deployed to staging.
   - Manual actions are provided for incremental rollout to production.
+## Using multiple Kubernetes clusters **(PREMIUM)**
+
+When using Auto DevOps, you may want to deploy different environments to
+different Kubernetes clusters. This is possible due to the 1:1 connection that
+[exists between them](../../user/project/clusters/index.md#multiple-kubernetes-clusters-premium).
+
+In the [Auto DevOps template] (used behind the scenes by Auto DevOps), there
+are currently 3 defined environment names that you need to know:
+
+- `review/` (every environment starting with `review/`)
+- `staging`
+- `production`
+
+Those environments are tied to jobs that use [Auto Deploy](#auto-deploy), so
+except for the environment scope, they would also need to have a different
+domain they would be deployed to. This is why you need to define a separate
+`KUBE_INGRESS_BASE_DOMAIN` variable for all the above
+[based on the environment](../../ci/variables/README.md#limiting-environment-scopes-of-environment-variables).
+
+The following table is an example of how the three different clusters would
+be configured.
+
+| Cluster name | Cluster environment scope | `KUBE_INGRESS_BASE_DOMAIN` variable value | Variable environment scope | Notes |
+|--------------|---------------------------|-------------------------------------------|----------------------------|---|
+| review       | `review/*`                | `review.example.com`                      | `review/*`                 | The review cluster which will run all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, which means it will be used by every environment name starting with `review/`. |
+| staging      | `staging`                 | `staging.example.com`                     | `staging`                  | (Optional) The staging cluster which will run the deployments of the staging environments. You need to [enable it first](#deploy-policy-for-staging-and-production-environments). |
+| production   | `production`              | `example.com`                             | `production`               | The production cluster which will run the deployments of the production environment. You can use [incremental rollouts](#incremental-rollout-to-production-premium). |
+
+To add a different cluster for each environment:
+
+1. Navigate to your project's **Operations > Kubernetes** and create the Kubernetes clusters
+   with their respective environment scope as described from the table above.
+
+   ![Auto DevOps multiple clusters](img/autodevops_multiple_clusters.png)
+
+1. After the clusters are created, navigate to each one and install Helm Tiller
+   and Ingress. Wait for the Ingress IP address to be assigned.
+1. Make sure you have [configured your DNS](#auto-devops-base-domain) with the
+   specified Auto DevOps domains.
+1. Navigate to each cluster's page, through **Operations > Kubernetes**,
+   and add the domain based on its Ingress IP address.
+
+Now that all is configured, you can test your setup by creating a merge request
+and verifying that your app is deployed as a review app in the Kubernetes
+cluster with the `review/*` environment scope. Similarly, you can check the
+other environments.
+
 ## Stages of Auto DevOps
 The following sections describe the stages of Auto DevOps. Read them carefully
@@ -672,8 +700,6 @@ workers:
 ### Auto Monitoring
-See the [requirements](#requirements) for Auto Monitoring to enable this stage.
-
 Once your application is deployed, Auto Monitoring makes it possible to monitor
 your application's server and response metrics right out of the box. Auto
 Monitoring uses [Prometheus](../../user/project/integrations/prometheus.md) to
@@ -687,18 +713,15 @@ The metrics include:
 - **Response Metrics:** latency, throughput, error rate
 - **System Metrics:** CPU utilization, memory utilization
-In order to make use of monitoring you need to:
-
-1. [Deploy Prometheus](../../user/project/integrations/prometheus.md) into your Kubernetes cluster
-1. If you would like response metrics, ensure you are running at least version
-   0.9.0 of NGINX Ingress and
-   [enable Prometheus metrics](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/customization/custom-vts-metrics-prometheus/nginx-vts-metrics-conf.yaml).
-1. Finally, [annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
-   the NGINX Ingress deployment to be scraped by Prometheus using
-   `prometheus.io/scrape: "true"` and `prometheus.io/port: "10254"`.
-To view the metrics, open the
-[Monitoring dashboard for a deployed environment](../../ci/environments.md#monitoring-environments).
+To make use of Auto Monitoring:
+1. [Install and configure the requirements](#requirements).
+1. [Enable Auto DevOps](#enablingdisabling-auto-devops) if you haven't done already.
+1. Finally, go to your project's **CI/CD > Pipelines** and run a pipeline.
+1. Once the pipeline finishes successfully, open the
+   [monitoring dashboard for a deployed environment](../../ci/environments.md#monitoring-environments)
+   to view the metrics of your deployed application. To view the metrics of the
+   whole Kubernetes cluster, navigate to **Operations > Metrics**.
 ![Auto Metrics](img/auto_monitoring.png)
@@ -1303,7 +1326,6 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/
 ```
 [ce-37115]: https://gitlab.com/gitlab-org/gitlab-foss/issues/37115
-[kubernetes-clusters]: ../../user/project/clusters/index.md
 [docker-in-docker]: ../../docker/using_docker_build.md#use-docker-in-docker-executor
 [review-app]: ../../ci/review_apps/index.md
 [container-registry]: ../../user/packages/container_registry/index.md

doc/topics/autodevops/quick_start_guide.md

@@ -280,6 +280,6 @@ and customized to fit your workflow. Here are some helpful resources for further
 1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters-premium) **(PREMIUM)**
 1. [Incremental rollout to production](index.md#incremental-rollout-to-production-premium) **(PREMIUM)**
 1. [Disable jobs you don't need with environment variables](index.md#environment-variables)
-1. [Use a static IP for your cluster](../../user/project/clusters/index.md#using-a-static-ip)
+1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
 1. [Use your own buildpacks to build your application](index.md#custom-buildpacks)
 1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)

doc/user/clusters/applications.md

@@ -107,10 +107,20 @@ To resolve this:
 project that is used to run your jobs and send the results back to
 GitLab. It is used in conjunction with [GitLab
 CI/CD](../../ci/README.md), the open-source continuous integration
-service included with GitLab that coordinates the jobs. When installing
-the GitLab Runner via the applications, it will run in **privileged
-mode** by default. Make sure you read the [security
-implications](../project/clusters/index.md#security-implications) before doing so.
+service included with GitLab that coordinates the jobs.
+
+If the project is on GitLab.com, shared Runners are available
+(the first 2000 minutes are free, you can
+[buy more later](../../subscriptions/index.md#extra-shared-runners-pipeline-minutes))
+and you do not have to deploy one if they are enough for your needs. If a
+project-specific Runner is desired, or there are no shared Runners, it is easy
+to deploy one.
+
+Note that the deployed Runner will be set as **privileged**, which means it will essentially
+have root access to the underlying machine. This is required to build Docker images,
+so it is the default. Make sure you read the
+[security implications](../project/clusters/index.md#security-implications)
+before deploying one.
 NOTE: **Note:**
 The [`runner/gitlab-runner`](https://gitlab.com/gitlab-org/charts/gitlab-runner)
@@ -128,12 +138,113 @@ balancing, SSL termination, and name-based virtual hosting. It acts as a
 web proxy for your applications and is useful if you want to use [Auto
 DevOps](../../topics/autodevops/index.md) or deploy your own web apps.
+NOTE: **Note:**
+With the following procedure, a load balancer must be installed in your cluster
+to obtain the endpoint. You can use either
+Ingress, or Knative's own load balancer ([Istio](https://istio.io)) if using Knative.
+
+In order to publish your web application, you first need to find the endpoint which will be either an IP
+address or a hostname associated with your load balancer.
+
+To install it, click on the **Install** button for Ingress. GitLab will attempt
+to determine the external endpoint and it should be available within a few minutes.
+
+#### Determining the external endpoint automatically
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/17052) in GitLab 10.6.
+
+After you install Ingress, the external endpoint should be available within a few minutes.
+
+TIP: **Tip:**
+This endpoint can be used for the
+[Auto DevOps base domain](../../topics/autodevops/index.md#auto-devops-base-domain)
+using the `KUBE_INGRESS_BASE_DOMAIN` environment variable.
+
+If the endpoint doesn't appear and your cluster runs on Google Kubernetes Engine:
+
+1. Check your [Kubernetes cluster on Google Kubernetes Engine](https://console.cloud.google.com/kubernetes) to ensure there are no errors on its nodes.
+1. Ensure you have enough [Quotas](https://console.cloud.google.com/iam-admin/quotas) on Google Kubernetes Engine. For more information, see [Resource Quotas](https://cloud.google.com/compute/quotas).
+1. Check [Google Cloud's Status](https://status.cloud.google.com/) to ensure they are not having any disruptions.
+
+Once installed, you may see a `?` for "Ingress IP Address" depending on the
+cloud provider. For EKS specifically, this is because the ELB is created
+with a DNS name, not an IP address. If GitLab is still unable to
+determine the endpoint of your Ingress or Knative application, you can
+[determine it manually](#determining-the-external-endpoint-manually).
+
 NOTE: **Note:**
 The [`stable/nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
 chart is used to install this application with a
 [`values.yaml`](https://gitlab.com/gitlab-org/gitlab/blob/master/vendor/ingress/values.yaml)
 file.
+#### Determining the external endpoint manually
+
+If the cluster is on GKE, click the **Google Kubernetes Engine** link in the
+**Advanced settings**, or go directly to the
+[Google Kubernetes Engine dashboard](https://console.cloud.google.com/kubernetes/)
+and select the proper project and cluster. Then click **Connect** and execute
+the `gcloud` command in a local terminal or using the **Cloud Shell**.
+
+If the cluster is not on GKE, follow the specific instructions for your
+Kubernetes provider to configure `kubectl` with the right credentials.
+The output of the following examples will show the external endpoint of your
+cluster. This information can then be used to set up DNS entries and forwarding
+rules that allow external access to your deployed applications.
+
+If you installed Ingress via the **Applications**, run the following command:
+
+```bash
+kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
+```
+
+Some Kubernetes clusters return a hostname instead, like [Amazon EKS](https://aws.amazon.com/eks/). For these platforms, run:
+
+```bash
+kubectl get service --namespace=gitlab-managed-apps ingress-nginx-ingress-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
+```
+
+For Istio/Knative, the command will be different:
+
+```bash
+kubectl get svc --namespace=istio-system knative-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip} '
+```
+
+Otherwise, you can list the IP addresses of all load balancers:
+
+```bash
+kubectl get svc --all-namespaces -o jsonpath='{range.items[?(@.status.loadBalancer.ingress)]}{.status.loadBalancer.ingress[*].ip} '
+```
+
+NOTE: **Note:**
+If EKS is used, an [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/)
+will also be created, which will incur additional AWS costs.
+
+NOTE: **Note:**
+You may see a trailing `%` on some Kubernetes versions, **do not include it**.
+
+The Ingress is now available at this address and will route incoming requests to
+the proper service based on the DNS name in the request. To support this, a
+wildcard DNS CNAME record should be created for the desired domain name. For example,
+`*.myekscluster.com` would point to the Ingress hostname obtained earlier.
+
+#### Using a static IP
+
+By default, an ephemeral external IP address is associated to the cluster's load
+balancer. If you associate the ephemeral IP with your DNS and the IP changes,
+your apps will not be able to be reached, and you'd have to change the DNS
+record again. In order to avoid that, you should change it into a static
+reserved IP.
+
+Read how to [promote an ephemeral external IP address in GKE](https://cloud.google.com/compute/docs/ip-addresses/reserve-static-external-ip-address#promote_ephemeral_ip).
+
+#### Pointing your DNS at the external endpoint
+
+Once you've set up the external endpoint, you should associate it with a [wildcard DNS
+record](https://en.wikipedia.org/wiki/Wildcard_DNS_record) such as `*.example.com.`
+in order to be able to reach your apps. If your external endpoint is an IP address,
+use an A record. If your external endpoint is a hostname, use a CNAME record.
+
 #### Web Application Firewall (ModSecurity)
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/65192) in GitLab 12.3 (enabled using `ingress_modsecurity` [feature flag](../../development/feature_flags/development.md#enabling-a-feature-flag-in-development)).
@@ -259,6 +370,14 @@ chart is used to install this application.
 open-source monitoring and alerting system useful to supervise your
 deployed applications.
+GitLab is able to monitor applications automatically, using the
+[Prometheus integration](../project/integrations/prometheus.md). Kubernetes container CPU and
+memory metrics are automatically collected, and response metrics are retrieved
+from NGINX Ingress as well.
+
+To enable monitoring, simply install Prometheus into the cluster with the
+**Install** button.
+
 NOTE: **Note:**
 The [`stable/prometheus`](https://github.com/helm/charts/tree/master/stable/prometheus)
 chart is used to install this application with a

doc/user/packages/npm_registry/index.md

@@ -42,6 +42,9 @@ it is not possible due to a naming collision. For example:
 | `gitlab-org/gitlab`    | `@gitlab-org/gitlab`    | Yes       |
 | `gitlab-org/gitlab`    | `@foo/bar`              | No        |
+CAUTION: **When updating the path of a user/group or transferring a (sub)group/project:**
+If you update the root namespace of a project with NPM packages, your changes will be rejected. To be allowed to do that, make sure to remove any NPM package first. Don't forget to update your `.npmrc` files to follow the above naming convention and run `npm publish` if necessary.
+
 Now, you can configure your project to authenticate with the GitLab NPM
 Registry.