Add latest changes from gitlab-org/gitlab@master

app/models/clusters/applications/cert_manager.rb

@@ -65,7 +65,7 @@ module Clusters
       end
 
       def retry_command(command)
-        "for i in $(seq 1 30); do #{command} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
+        "for i in $(seq 1 30); do #{command} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)"
       end
 
       def post_delete_script

doc/administration/geo/replication/configuration.md

@@ -165,10 +165,32 @@ keys must be manually replicated to the **secondary** node.
 
 ### Step 3. Add the **secondary** node
 
+1. SSH into your GitLab **secondary** server and login as root:
+
+   ```sh
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node.  You will need this in the next steps:
+
+   ```ruby
+   # The unique identifier for the Geo node.
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+   ```
+
+1. Reconfigure the **secondary** node for the change to take effect:
+
+   ```sh
+   gitlab-ctl reconfigure
+   ```
+
 1. Visit the **primary** node's **Admin Area > Geo**
    (`/admin/geo/nodes`) in your browser.
-1. Add the **secondary** node by providing its full URL. **Do NOT** check the
+1. Click the **New node** button.
+1. Add the **secondary** node. Use the **exact** name you inputed for `gitlab_rails['geo_node_name']` as the Name and the full URL as the URL.  **Do NOT** check the
    **This is a primary node** checkbox.
+
+   ![Add secondary node](img/adding_a_secondary_node.png)
 1. Optionally, choose which groups or storage shards should be replicated by the
    **secondary** node. Leave blank to replicate all. Read more in
    [selective synchronization](#selective-synchronization).

doc/administration/geo/replication/database.md

@@ -53,6 +53,19 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    sudo -i
    ```
 
+1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node:
+
+   ```ruby
+   # The unique identifier for the Geo node.
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+   ```
+
+1. Reconfigure the **primary** node for the change to take effect:
+
+   ```sh
+   gitlab-ctl reconfigure
+   ```
+
 1. Execute the command below to define the node as **primary** node:
 
    ```sh

doc/administration/geo/replication/high_availability.md

@@ -56,6 +56,11 @@ The following steps enable a GitLab cluster to serve as the **primary** node.
    ##
    roles ['geo_primary_role']
 
+   ##
+   ## The unique identifier for the Geo node.
+   ##
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+
    ##
    ## Disable automatic migrations
    ##
@@ -229,6 +234,11 @@ following modifications:
    ##
    roles ['geo_secondary_role', 'application_role']
 
+   ##
+   ## The unique identifier for the Geo node.
+   ##
+   gitlab_rails['geo_node_name'] = '<node_name_here>'
+
    ##
    ## Disable automatic migrations
    ##

doc/administration/libravatar.md

+---
+type: howto
+---
+
+# Using the Libravatar service with GitLab
+
+GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
+
+Libravatar is another service that delivers your avatar (profile picture) to
+other websites. The Libravatar API is
+[heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
+easily switch to the Libravatar avatar service or even a self-hosted Libravatar
+server.
+
+## Configuration
+
+In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
+the configuration options as follows:
+
+### For HTTP
+
+```yml
+  gravatar:
+    enabled: true
+    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
+    plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+### For HTTPS
+
+```yml
+  gravatar:
+    enabled: true
+    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
+    ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+### Self-hosted Libravatar server
+
+If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
+the URL will be different in the configuration, but you must provide the same
+placeholders so GitLab can parse the URL correctly.
+
+For example, you host a service on `http://libravatar.example.com` and the
+`plain_url` you need to supply in `gitlab.yml` is
+
+`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
+
+### Omnibus GitLab example
+
+In `/etc/gitlab/gitlab.rb`:
+
+#### For HTTP
+
+```ruby
+gitlab_rails['gravatar_enabled'] = true
+gitlab_rails['gravatar_plain_url'] = "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+#### For HTTPS
+
+```ruby
+gitlab_rails['gravatar_enabled'] = true
+gitlab_rails['gravatar_ssl_url'] = "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
+```
+
+Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
+
+## Default URL for missing images
+
+[Libravatar supports different sets](https://wiki.libravatar.org/api/) of
+missing images for user email addresses that are not found on the Libravatar
+service.
+
+In order to use a set other than `identicon`, replace the `&d=identicon`
+portion of the URL with another supported set.
+For example, you can use the `retro` set, in which case the URL would look like:
+`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
+
+## Usage examples for Microsoft Office 365
+
+If your users are Office 365 users, the `GetPersonaPhoto` service can be used.
+Note that this service requires a login, so this use case is most useful in a
+corporate installation where all users have access to Office 365.
+
+```ruby
+gitlab_rails['gravatar_plain_url'] = 'http://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
+gitlab_rails['gravatar_ssl_url'] = 'https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
+```
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->

doc/customization/branded_login_page.md

 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#sign-in--sign-up-pages'
 ---
 
-# Changing the logo and description on the login page
-
-You can customize the login page of your GitLab server to show the logo and
-description of your organization.
-
-By default, the page shows the GitLab logo and description:
-
-![default_login_page](branded_login_page/default_login_page.png)
-
-To customize the login page:
-
-1. Navigate to the **Admin** area and go to the **Appearance** page.
-1. Fill in your desired Title and Description. You can also choose an image file
-   of the logo for your organization.
-
-   ![appearance](branded_login_page/appearance.png)
-
-1. Save your changes.
-
-Your GitLab login page will display the details you provided:
-
-![company_login_page](branded_login_page/custom_sign_in.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../user/admin_area/appearance.md#sign-in--sign-up-pages).

doc/customization/branded_page_and_email_header.md

 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#navigation-bar'
 ---
 
-# Changing the navigation bar and email header logo
-
-You can customize the logo that appears in email headers and in the navigation
-bar on pages that are displayed by your GitLab server.
-
-1. Navigate to the **Admin** area and go to the **Appearance** page, then locate
-   the **Navigation bar** section.
-1. For the **Header Logo**, choose an image file of the logo for your
-   organization.
-
-   ![appearance](branded_page_and_email_header/appearance.png)
-
-1. Save your changes.
-
-Your GitLab navigation bar will display the custom logo:
-
-![custom_brand_header](branded_page_and_email_header/custom_brand_header.png)
-
-The GitLab pipeline emails will also display the custom logo:
-
-![custom_email_header](branded_page_and_email_header/custom_email_header.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../user/admin_area/appearance.md#navigation-bar).

doc/customization/favicon.md

 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#favicon'
 ---
 
-# Changing the favicon
-
-> [Introduced][ce-14497] in GitLab 11.0.
-
-[ce-14497]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14497
-
-You can customize the favicon (the icon displayed in your web browser's
-address bar and web page tabs) for your GitLab server.
-
-1. Navigate to the **Admin** area and go to the **Appearance** page, then
-   locate the **Favicon** section.
-1. Upload an image file of your favicon.
-
-   ![appearance](favicon/appearance.png)
-
-1. Save your changes.
-
-Your new favicon will display in the browser. The main favicon and the CI
-status icons will show the custom icon:
-
-![custom_favicon](favicon/custom_favicon.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../user/admin_area/appearance.md#favicon).

doc/customization/help_message.md

 ---
-type: howto
+redirect_to: '../user/admin_area/settings/help_page.md'
 ---
 
-# Customizing the 'Help' and login page messages
-
-In large organizations, it is useful to have information about who maintains
-the company GitLab server. You can customize and display this information on
-the GitLab login page and on the GitLab server's `/help` page.
-
-1. Navigate to the **Admin** area, then click on **Preferences** and expand
-   **Help page**.
-1. Under **Help page text**, fill in the required information about the
-   person(s) administering GitLab. This text can also contain any other
-   information that you wish to display to users.
-
-   ![help message](help_message/help_text.png)
-
-1. Save your changes.
-
-The information you entered will be shown on the GitLab login page and on the
-GitLab `/help` page (e.g., <https://gitlab.com/help>).
-
-![help text on help page](help_message/help_text_on_help_page.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../user/admin_area/settings/help_page.md).

doc/customization/index.md

 ---
-type: index
-description: Learn how to customize GitLab's appearance for self-managed installations.
+redirect_to: '../user/admin_area/appearance.md'
 ---
 
-# Customizing GitLab's appearance **(CORE ONLY)**
-
-For GitLab self-managed instances, you can customize the page logo,
-email headers, favicon, and several other aspects of GitLab's appearance.
-
-The following pages explain how to customize the appearance of your instance:
-
-- [Changing the logo and description on the login page](branded_login_page.md)
-- [Changing the navigation bar and email header logo](branded_page_and_email_header.md)
-- [Changing the favicon](favicon.md)
-- [Customizing the new project page](new_project_page.md)
-- [Customizing the `/help` and login page messages](help_message.md)
-- [Using the Libravatar service with GitLab](libravatar.md)
+This document was moved to [another location](../user/admin_area/appearance.md).

doc/customization/libravatar.md

 ---
-type: howto
+redirect_to: '../administration/libravatar.md'
 ---
 
-# Using the Libravatar service with GitLab
-
-GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
-
-Libravatar is another service that delivers your avatar (profile picture) to
-other websites. The Libravatar API is
-[heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
-easily switch to the Libravatar avatar service or even a self-hosted Libravatar
-server.
-
-## Configuration
-
-In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
-the configuration options as follows:
-
-### For HTTP
-
-```yml
-  gravatar:
-    enabled: true
-    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
-    plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-### For HTTPS
-
-```yml
-  gravatar:
-    enabled: true
-    # gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
-    ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-### Self-hosted Libravatar server
-
-If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
-the URL will be different in the configuration, but you must provide the same
-placeholders so GitLab can parse the URL correctly.
-
-For example, you host a service on `http://libravatar.example.com` and the
-`plain_url` you need to supply in `gitlab.yml` is
-
-`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
-
-### Omnibus GitLab example
-
-In `/etc/gitlab/gitlab.rb`:
-
-#### For HTTP
-
-```ruby
-gitlab_rails['gravatar_enabled'] = true
-gitlab_rails['gravatar_plain_url'] = "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-#### For HTTPS
-
-```ruby
-gitlab_rails['gravatar_enabled'] = true
-gitlab_rails['gravatar_ssl_url'] = "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
-```
-
-Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
-
-## Default URL for missing images
-
-[Libravatar supports different sets](https://wiki.libravatar.org/api/) of
-missing images for user email addresses that are not found on the Libravatar
-service.
-
-In order to use a set other than `identicon`, replace the `&d=identicon`
-portion of the URL with another supported set.
-For example, you can use the `retro` set, in which case the URL would look like:
-`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
-
-## Usage examples for Microsoft Office 365
-
-If your users are Office 365 users, the `GetPersonaPhoto` service can be used.
-Note that this service requires a login, so this use case is most useful in a
-corporate installation where all users have access to Office 365.
-
-```ruby
-gitlab_rails['gravatar_plain_url'] = 'http://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
-gitlab_rails['gravatar_ssl_url'] = 'https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
-```
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../administration/libravatar.md).

doc/customization/new_project_page.md

 ---
-type: howto
+redirect_to: '../user/admin_area/appearance.md#new-project-pages'
 ---
 
-# Customizing the new project page
-
-You can add a markdown-formatted message to your GitLab new project page.
-
-By default, the new project page shows a sidebar with general information:
-
-![default_new_project_page](new_project_page/default_new_project_page.png)
-
-To customize the information in the sidebar:
-
-1. Navigate to the **Admin** area and go to the **Appearance** page, then
-   locate the **New project pages** section.
-1. Fill in your new project project guidelines:
-
-   ![appearance_settings](new_project_page/appearance_settings.png)
-
-1. Save the page.
-
-Your new project page will show the customized guidelines in the sidebar, below
-the general information:
-
-![custom_new_project_page](new_project_page/custom_new_project_page.png)
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../user/admin_area/appearance.md#new-project-pages).

doc/customization/system_header_and_footer_messages.md

-# Adding a system message to every page
+---
+redirect_to: '../user/admin_area/appearance.md#system-header-and-footer-messages'
+---
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
-> [Added](https://gitlab.com/gitlab-org/gitlab-foss/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
-
-Navigate to the **Admin** area and go to the **Appearance** page.
-
-Under **System header and footer** insert your header message and/or footer message.
-Both background and font color of the header and footer are customizable.
-
-You can also apply the header and footer messages to GitLab emails,
-by checking the **Enable header and footer in emails** checkbox.
-Note that color settings will only be applied within the app interface and not to emails
-
-![appearance](system_header_and_footer_messages/appearance.png)
-
-After saving, all pages within GitLab will contain the custom system header and/or footer messages:
-
-![custom_header_footer](system_header_and_footer_messages/custom_header_footer.png)
-
-The GitLab sign in page will also show the header and the footer messages:
-
-![sign_up_custom_header_and_footer](system_header_and_footer_messages/sign_up_custom_header_and_footer.png)
+This document was moved to [another location](../user/admin_area/appearance.md#system-header-and-footer-messages).

doc/topics/autodevops/quick_start_guide.md

@@ -35,16 +35,16 @@ those projects provide a barebones application built on some well-known framewor
 1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select
    **New project**.
 1. Go to the **Create from template** tab where you can choose among a Ruby on
-   Rails, Spring, or NodeJS Express project. For this example,
-   we'll use the Ruby on Rails template.
+   Rails, Spring, or NodeJS Express project.
+   We'll use the Ruby on Rails template.
 
-   ![Select project template](img/guide_project_template.png)
+   ![Select project template](img/guide_project_template_v12_3.png)
 
 1. Give your project a name, optionally a description, and make it public so that
    you can take advantage of the features available in the
    [GitLab Gold plan](https://about.gitlab.com/pricing/#gitlab-com).
 
-   ![Create project](img/guide_create_project.png)
+   ![Create project](img/guide_create_project_v12_3.png)
 
 1. Click **Create project**.
 
@@ -56,37 +56,30 @@ under which this application will be deployed.
 1. On the project's landing page, click the button labeled **Add Kubernetes cluster**
    (note that this option is also available when you navigate to **Operations > Kubernetes**).
 
-   ![Project landing page](img/guide_project_landing_page.png)
+   ![Project landing page](img/guide_project_landing_page_v12_3.png)
 
-1. Choose **Create on Google Kubernetes Engine**.
+1. One the **Create new cluster on GKE** tab, click "Sign in with Google".
 
-   ![Choose GKE](img/guide_choose_gke.png)
-
-1. Sign in with Google.
-
-   ![Google sign in](img/guide_google_signin.png)
+   ![Google sign in](img/guide_google_signin_v12_3.png)
 
 1. Connect with your Google account and press **Allow** when asked (this will
    be shown only the first time you connect GitLab with your Google account).
 
-   ![Google auth](img/guide_google_auth.png)
+   ![Google auth](img/guide_google_auth_v12_3.png)
 
-1. The last step is to fill in the cluster details. Give it a name, leave the
+1. The last step is to provide the cluster details. Give it a name, leave the
    environment scope as is, and choose the GCP project under which the cluster
    will be created. (Per the instructions when you
    [configured your Google account](#configuring-your-google-account), a project
    should have already been created for you.) Next, choose the
    [region/zone](https://cloud.google.com/compute/docs/regions-zones/) under which the
    cluster will be created, enter the number of nodes you want it to have, and
-   finally choose their [machine type](https://cloud.google.com/compute/docs/machine-types).
+   finally choose the [machine type](https://cloud.google.com/compute/docs/machine-types).
 
-   ![GitLab GKE cluster details](img/guide_gitlab_gke_details.png)
+   ![GitLab GKE cluster details](img/guide_gitlab_gke_details_v12_3.png)
 
 1. Once ready, click **Create Kubernetes cluster**.
 
-NOTE: **Note:**
-Do not select `f1-micro` from the **Machine type** dropdown. `f1-micro` machines cannot support a full GitLab installation.
-
 After a couple of minutes, the cluster will be created. You can also see its
 status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
 
@@ -99,7 +92,7 @@ GitLab's Kubernetes integration comes with some
 [pre-defined applications](../../user/project/clusters/index.md#installing-applications)
 for you to install.
 
-![Cluster applications](img/guide_cluster_apps.png)
+![Cluster applications](img/guide_cluster_apps_v12_3.png)
 
 The first one to install is Helm Tiller, a package manager for Kubernetes, which
 is needed in order to install the rest of the applications. Go ahead and click
@@ -113,32 +106,31 @@ use to supervise the deployed application. We will not install GitLab Runner as
 we'll use the shared Runners that GitLab.com provides.
 
 After the Ingress is installed, wait a few seconds and copy the IP address that
-is displayed, which we'll use in the next step when enabling Auto DevOps.
+is displayed in order to add in your base **Domain** at the top of the page. For
+the purpose of this guide, we will use the one suggested by GitLab. Once you have
+filled in the domain, click **Save changes**.
+
+![Cluster Base Domain](img/guide_base_domain_v12_3.png)
 
-## Enabling Auto DevOps
+## Enabling Auto DevOps (optional)
 
-Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps.
+Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable
+Auto DevOps at both the instance-level (for self-managed instances) and also at the group-level.
+Follow these steps if Auto DevOps has been manually disabled.
 
 1. First, navigate to **Settings > CI/CD > Auto DevOps**.
-1. Select **Enable Auto DevOps**.
-1. Add in your base **Domain** by using the one GitLab suggests. Note that
-   generally, you would associate the IP address with a domain name on your
-   registrar's settings. In this case, for the sake of the guide, we will use
-   an alternative DNS that will map any domain name of the scheme
-   `anything.ip_address.nip.io` to the corresponding `ip_address`. For example,
-   if the IP address of the Ingress is `1.2.3.4`, the domain name to fill in
-   would be `1.2.3.4.nip.io`.
+1. Select **Default to Auto DevOps pipeline**.
 1. Lastly, let's select the [continuous deployment strategy](index.md#deployment-strategy)
    which will automatically deploy the application to production once the pipeline
    successfully runs on the `master` branch.
 1. Click **Save changes**.
 
-   ![Auto DevOps settings](img/guide_enable_autodevops.png)
+   ![Auto DevOps settings](img/guide_enable_autodevops_v12_3.png)
 
 Once you complete all the above and save your changes, a new pipeline is
 automatically created. To view the pipeline, go to **CI/CD > Pipelines**.
 
-![First pipeline](img/guide_first_pipeline.png)
+![First pipeline](img/guide_first_pipeline_v12_3.png)
 
 In the next section we'll break down the pipeline and explain what each job does.
 
@@ -149,7 +141,7 @@ By now you should see the pipeline running, but what is it running exactly?
 To navigate inside the pipeline, click its status badge. (Its status should be "running").
 The pipeline is split into 4 stages, each running a couple of jobs.
 
-![Pipeline stages](img/guide_pipeline_stages.png)
+![Pipeline stages](img/guide_pipeline_stages_v12_3.png)
 
 In the **build** stage, the application is built into a Docker image and then
 uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](index.md#auto-build)).
@@ -190,7 +182,7 @@ page where you can also monitor your application. Let's explore that.
 Now that the application is successfully deployed, let's navigate to its
 website. First, go to **Operations > Environments**.
 
-![Environments](img/guide_environments.png)
+![Environments](img/guide_environments_v12_3.png)
 
 In **Environments** you can see some details about the deployed
 applications. In the rightmost column for the production environment, you can make use of the three icons:
@@ -201,7 +193,7 @@ applications. In the rightmost column for the production environment, you can ma
   Prometheus collects data about the Kubernetes cluster and how the application
   affects it (in terms of memory/CPU usage, latency, etc.).
 
-  ![Environments metrics](img/guide_environments_metrics.png)
+  ![Environments metrics](img/guide_environments_metrics_v12_3.png)
 
 - The third icon is the [web terminal](../../ci/environments.md#web-terminals)
   and it will open a terminal session right inside the container where the
@@ -235,13 +227,13 @@ you're on the Web IDE, make the following change:
 Stage the file, add a commit message, and create a new branch and a merge request
 by clicking **Commit**.
 
-![Web IDE commit](img/guide_ide_commit.png)
+![Web IDE commit](img/guide_ide_commit_v12_3.png)
 
 Once you submit the merge request, you'll see the pipeline running. This will
 run all the jobs as [described previously](#deploying-the-application), as well as
 a few more that run only on branches other than `master`.
 
-![Merge request](img/guide_merge_request.png)
+![Merge request](img/guide_merge_request_v12_3.png)
 
 After a few minutes you'll notice that there was a failure in a test.
 This means there's a test that was 'broken' by our change.
@@ -259,7 +251,7 @@ bin/rails test test/controllers/welcome_controller_test.rb:4
 
 Let's fix that:
 
-1. Back to the merge request, click the **Web IDE** button.
+1. Back to the merge request, click the **Open in Web IDE** button.
 1. Find the `test/controllers/welcome_controller_test.rb` file and open it.
 1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
 1. Click **Commit**.
@@ -269,10 +261,10 @@ Let's fix that:
 
 Now, if you go back to the merge request you should not only see the test passing, but
 also the application deployed as a [review app](index.md#auto-review-apps). You
-can visit it by following the URL in the merge request. The changes that we
-previously made should be there.
+can visit it by following clicking the **View app** button. You will see
+the changes that we previously made.
 
-![Review app](img/guide_merge_request_review_app.png)
+![Review app](img/guide_merge_request_review_app_v12_3.png)
 
 Once you merge the merge request, the pipeline will run on the `master` branch,
 and the application will be eventually deployed straight to production.

doc/user/admin_area/appearance.md

+---
+type: howto
+disqus_identifier: 'https://docs.gitlab.com/ee/customization/branded_login_page.html'
+---
+
+# GitLab Appearance **(CORE ONLY)**
+
+There are several options for customizing the appearance of a self hosted instance
+of GitLab. These settings are accessed from the **Admin Area** in the **Appearance**
+section.
+
+## Navigation bar
+
+By default, the navigation bar has the GitLab logo, but this can be customized with
+any image desired. It is optimized for images 28px high (any width), but any image can be
+used (less than 1MB) and it will automatically be resized.
+
+![navbar header logo screenshot](img/appearance_header_logo_v12_3.png)
+
+Once you select and upload an image, click **Update appearance settings** at the bottom
+of the page to activate it in the GitLab instance.
+
+NOTE: **Note:**
+GitLab pipeline emails will also display the custom logo.
+
+## Favicon
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14497) in GitLab 11.0.
+
+By default, the favicon (used by the browser as the tab icon, as well as the CI status icon)
+uses the GitLab logo, but this can be customized with any icon desired. It must be a
+32x32 `.png` or `.ico` image.
+
+![favicon screenshot](img/appearance_favicon_v12_3.png)
+
+After you select and upload an icon, click **Update appearance settings** at the bottom
+of the page to activate it in the GitLab instance.
+
+## System header and footer messages
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
+> - [Added](https://gitlab.com/gitlab-org/gitlab-foss/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
+
+You can add a small header message, a small footer message, or both, to the interface
+of your GitLab instance. These messages will appear on all projects and pages of the
+instance, including the sign in / sign up page. The default color is white text on
+an orange background, but this can be customized by clicking on **Customize colors**.
+
+Limited [markdown](../markdown.md) is supported, such as bold, italics, and links, for
+example. Other markdown features, including lists, images and quotes, are not supported,
+as the header and footer messages can only be a single line.
+
+![header and footer screenshot](img/appearance_header_footer_v12_3.png)
+
+If desired, you can select **Enable header and footer in emails** to have the text of
+the header and footer added to all emails sent by the GitLab instance.
+
+After you add a message, click **Update appearance settings** at the bottom of the page
+to activate it in the GitLab instance.
+
+## Sign in / Sign up pages
+
+You can replace the default message on the sign in / sign up page with your own message
+and logo. You can make full use of [markdown](../markdown.md) in the description:
+
+![sign in message screenshot](img/appearance_sign_in_v12_3.png)
+
+The optimal size for the logo is 640x360px, but any image can be used (below 1MB)
+and it will be resized automatically. The logo image will appear between the title and
+the description, on the left of the sign-up page.
+
+![sign in message preview screenshot](img/appearance_sign_in_preview_v12_3.png)
+
+After you add a message, click **Update appearance settings** at the bottom of the page
+to activate it in the GitLab instance. You can also click on the **Sign-in page** button,
+to review the saved appearance settings:
+
+NOTE: **Note:**
+You can add also add a [customized help message](settings/help_page.md) below the sign in message.
+
+## New project pages
+
+You can add a new project guidelines message to the **New project page** within GitLab.
+You can make full use of [markdown](../markdown.md) in the description:
+
+![new project message screenshot](img/appearance_new_project_v12_3.png)
+
+The message will be displayed below the **New Project** message, on the left side
+of the **New project page**.
+
+After you add a message, click **Update appearance settings** at the bottom of the page
+to activate it in the GitLab instance. You can also click on the **New project page**
+button, which will bring you to the new project page so you can review the change.
+
+![new project message preview screenshot](img/appearance_new_project_preview_v12_3.png)
+
+## Libravatar
+
+[Libravatar](https://www.libravatar.org) is supported by GitLab for avatar images, but you must
+[manually enable Libravatar support on the GitLab instance](../../administration/libravatar.md)
+in order to use the service.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->

doc/user/admin_area/index.md

@@ -32,7 +32,7 @@ The Admin Area is made up of the following sections:
 | Deploy Keys                   | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys).                                                                                                                                                                                                                 |
 | Service Templates             | Create [service templates](../project/integrations/services_templates.md) for projects.                                                                                                                                                                                                  |
 | Labels                        | Create and maintain [labels](labels.md) for your GitLab instance.                                                                                                                                                                                                                        |
-| Appearance                    | Customize [GitLab's appearance](../../customization/index.md).                                                                                                                                                                                                                           |
+| Appearance                    | Customize [GitLab's appearance](appearance.md).                                                                                                                                                                                                                           |
 | Settings                      | Modify the [settings](settings/index.md) for your GitLab instance.                                                                                                                                                                                                                       |
 
 ## Admin Dashboard

doc/user/admin_area/settings/help_page.md

+---
+type: howto
+---
+
+# Customizing the 'Help' and login page messages
+
+In large organizations, it is useful to have information about who to contact or where
+to go for help. You can customize and display this information on the GitLab server's
+`/help` page and on the GitLab login page.
+
+## Adding a help message to the help page
+
+You can add a help message, which will be shown on the GitLab `/help` page (e.g.,
+<https://gitlab.com/help>) in a new section at the top of the `/help` page:
+
+1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
+1. Under **Help page text**, fill in the information you wish to display on `/help`.
+
+   ![help page help message](img/help_page_help_page_text_v12_3.png)
+
+1. Save your changes. You can now see the message on `/help`.
+
+![help message on help page example](img/help_page_help_page_text_ex_v12_3.png)
+
+## Adding a help message to the login page **(STARTER)**
+
+You can add a help message, which will be shown on the GitLab login page in a new section
+titled `Need Help?`, located below the login page message:
+
+1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
+1. Under **Help text**, fill in the information you wish to display on the login page.
+
+   ![help message on login page](img/help_page_help_text_v12_3.png)
+
+1. Save your changes.
+
+![help message on login page example](img/help_page_help_text_ex_v12_3.png)
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->

doc/user/admin_area/settings/index.md

@@ -21,6 +21,7 @@ include:
 - [User and IP rate limits](user_and_ip_rate_limits.md)
 - [Custom templates repository](instance_template_repository.md) **(PREMIUM)**
 - [Protected paths](protected_paths.md) **(CORE ONLY)**
+- [Help messages for the `/help` page and the login page](help_page.md)
 
 NOTE: **Note:**
 You can change the [first day of the week](../../profile/preferences.md) for the entire GitLab instance

lib/gitlab/kubernetes/helm/client_command.rb

@@ -17,7 +17,8 @@ module Gitlab
           # This is necessary to give Tiller time to restart after upgrade.
           # Ideally we'd be able to use --wait but cannot because of
           # https://github.com/helm/helm/issues/4855
-          "for i in $(seq 1 30); do #{helm_check} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
+
+          "for i in $(seq 1 30); do #{helm_check} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)"
         end
 
         def repository_command

spec/lib/gitlab/kubernetes/helm/delete_command_spec.rb

@@ -14,7 +14,7 @@ describe Gitlab::Kubernetes::Helm::DeleteCommand do
     let(:commands) do
       <<~EOS
       helm init --upgrade
-      for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
+      for i in $(seq 1 30); do helm version && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
       helm delete --purge app-name
       EOS
     end
@@ -36,7 +36,7 @@ describe Gitlab::Kubernetes::Helm::DeleteCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         #{helm_delete_command}
         EOS
       end

spec/lib/gitlab/kubernetes/helm/install_command_spec.rb

@@ -36,7 +36,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
     let(:commands) do
       <<~EOS
       helm init --upgrade
-      for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+      for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
       helm repo add app-name https://repository.example.com
       helm repo update
       #{helm_install_comand}
@@ -64,7 +64,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         helm repo add app-name https://repository.example.com
         helm repo update
         #{helm_install_command}
@@ -93,7 +93,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         #{helm_install_command}
         EOS
       end
@@ -120,7 +120,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         helm repo add app-name https://repository.example.com
         helm repo update
         /bin/date
@@ -151,7 +151,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         helm repo add app-name https://repository.example.com
         helm repo update
         #{helm_install_command}
@@ -182,7 +182,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         helm repo add app-name https://repository.example.com
         helm repo update
         #{helm_install_command}
@@ -210,7 +210,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
       let(:commands) do
         <<~EOS
         helm init --upgrade
-        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
         helm repo add app-name https://repository.example.com
         helm repo update
         #{helm_install_command}

spec/models/clusters/applications/cert_manager_spec.rb

@@ -54,7 +54,7 @@ describe Clusters::Applications::CertManager do
         'kubectl label --overwrite namespace gitlab-managed-apps certmanager.k8s.io/disable-validation=true'
       ])
       expect(subject.postinstall).to eq([
-        'for i in $(seq 1 30); do kubectl apply -f /data/helm/certmanager/config/cluster_issuer.yaml && break; sleep 1s; echo "Retrying ($i)..."; false; done'
+        "for i in $(seq 1 30); do kubectl apply -f /data/helm/certmanager/config/cluster_issuer.yaml && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)"
       ])
     end
 

spec/uploaders/attachment_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe AttachmentUploader do

spec/uploaders/avatar_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe AvatarUploader do

spec/uploaders/external_diff_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe ExternalDiffUploader do

spec/uploaders/file_mover_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe FileMover do

spec/uploaders/file_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe FileUploader do

spec/uploaders/gitlab_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 require 'carrierwave/storage/fog'
 

spec/uploaders/import_export_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe ImportExportUploader do

spec/uploaders/job_artifact_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe JobArtifactUploader do

spec/uploaders/lfs_object_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe LfsObjectUploader do

spec/uploaders/namespace_file_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe NamespaceFileUploader do

spec/uploaders/object_storage_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 require 'carrierwave/storage/fog'
 

spec/uploaders/personal_file_uploader_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe PersonalFileUploader do

spec/uploaders/records_uploads_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe RecordsUploads do

spec/uploaders/uploader_helper_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe UploaderHelper do

spec/uploaders/workers/object_storage/background_move_worker_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe ObjectStorage::BackgroundMoveWorker do

spec/uploaders/workers/object_storage/migrate_uploads_worker_spec.rb

+# frozen_string_literal: true
+
 require 'spec_helper'
 
 describe ObjectStorage::MigrateUploadsWorker, :sidekiq do