Add latest changes from gitlab-org/gitlab@master

app/controllers/groups_controller.rb

@@ -198,15 +198,13 @@ class GroupsController < Groups::ApplicationController
   def load_events
     params[:sort] ||= 'latest_activity_desc'
-    options = {}
-    options[:include_subgroups] = true
-
-    @projects = GroupProjectsFinder.new(params: params, group: group, options: options, current_user: current_user)
-                  .execute
-                  .includes(:namespace)
+    options = { include_subgroups: true }
+    projects = GroupProjectsFinder.new(params: params, group: group, options: options, current_user: current_user)
+                 .execute
+                 .includes(:namespace)
     @events = EventCollection
-                .new(@projects, offset: params[:offset].to_i, filter: event_filter)
+                .new(projects, offset: params[:offset].to_i, filter: event_filter, groups: groups)
                 .to_a
     Events::RenderService
@@ -228,6 +226,14 @@ class GroupsController < Groups::ApplicationController
     url_for(safe_params)
   end
+
+  private
+
+  def groups
+    if @group.supports_events?
+      @group.self_and_descendants.public_or_visible_to_user(current_user)
+    end
+  end
 end
 GroupsController.prepend_if_ee('EE::GroupsController')

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)...\"; done"
+        "for i in $(seq 1 30); do #{command} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
       end
       def post_delete_script

app/models/event.rb

@@ -77,15 +77,6 @@ class Event < ApplicationRecord
   scope :recent, -> { reorder(id: :desc) }
   scope :code_push, -> { where(action: PUSHED) }
-  scope :in_projects, -> (projects) do
-    sub_query = projects
-      .except(:order)
-      .select(1)
-      .where('projects.id = events.project_id')
-
-    where('EXISTS (?)', sub_query).recent
-  end
-
   scope :with_associations, -> do
     # We're using preload for "push_event_payload" as otherwise the association
     # is not always available (depending on the query being built).

app/models/event_collection.rb

@@ -6,6 +6,8 @@
 # in a controller), it's not suitable for building queries that are used for
 # building other queries.
 class EventCollection
+  include Gitlab::Utils::StrongMemoize
+
   # To prevent users from putting too much pressure on the database by cycling
   # through thousands of events we put a limit on the number of pages.
   MAX_PAGE = 10
@@ -13,57 +15,52 @@ class EventCollection
   # projects - An ActiveRecord::Relation object that returns the projects for
   #            which to retrieve events.
   # filter - An EventFilter instance to use for filtering events.
-  def initialize(projects, limit: 20, offset: 0, filter: nil)
+  def initialize(projects, limit: 20, offset: 0, filter: nil, groups: nil)
     @projects = projects
     @limit = limit
     @offset = offset
     @filter = filter
+    @groups = groups
   end
   # Returns an Array containing the events.
   def to_a
     return [] if current_page > MAX_PAGE
-    relation = if Gitlab::Database.join_lateral_supported?
-                 relation_with_join_lateral
+    relation = if groups
+                 project_and_group_events
                else
-                 relation_without_join_lateral
+                 relation_with_join_lateral('project_id', projects)
                end
+    relation = paginate_events(relation)
     relation.with_associations.to_a
   end
   private
-  # Returns the events relation to use when JOIN LATERAL is not supported.
-  #
-  # This relation simply gets all the events for all authorized projects, then
-  # limits that set.
-  def relation_without_join_lateral
-    events = filtered_events.in_projects(projects)
-    paginate_events(events)
+  def project_and_group_events
+    project_events = relation_with_join_lateral('project_id', projects)
+    group_events = relation_with_join_lateral('group_id', groups)
+    Event.from_union([project_events, group_events]).recent
   end
-  # Returns the events relation to use when JOIN LATERAL is supported.
-  #
   # This relation is built using JOIN LATERAL, producing faster queries than a
   # regular LIMIT + OFFSET approach.
-  def relation_with_join_lateral
-    projects_for_lateral = projects.select(:id).to_sql
+  def relation_with_join_lateral(parent_column, parents)
+    parents_for_lateral = parents.select(:id).to_sql
     lateral = filtered_events
       .limit(limit_for_join_lateral)
-      .where('events.project_id = projects_for_lateral.id')
+      .where("events.#{parent_column} = parents_for_lateral.id") # rubocop:disable GitlabSecurity/SqlInjection
       .to_sql
     # The outer query does not need to re-apply the filters since the JOIN
     # LATERAL body already takes care of this.
-    outer = base_relation
-      .from("(#{projects_for_lateral}) projects_for_lateral")
+    base_relation
+      .from("(#{parents_for_lateral}) parents_for_lateral")
       .joins("JOIN LATERAL (#{lateral}) AS #{Event.table_name} ON true")
-
-    paginate_events(outer)
   end
   def filtered_events
@@ -97,4 +94,10 @@ class EventCollection
   def projects
     @projects.except(:order)
   end
+
+  def groups
+    strong_memoize(:groups) do
+      groups.except(:order) if @groups
+    end
+  end
 end

app/models/group.rb

@@ -436,6 +436,10 @@ class Group < Namespace
     members.owners.order_recent_sign_in.limit(ACCESS_REQUEST_APPROVERS_TO_BE_NOTIFIED_LIMIT)
   end
+  def supports_events?
+    false
+  end
+
   private
   def update_two_factor_requirement

app/views/groups/_activities.html.haml

 .nav-block.activities
-  = render 'shared/event_filter'
+  = render 'shared/event_filter', show_group_events: @group.supports_events?
   .controls
     = link_to group_path(@group, rss_url_options), class: 'btn d-none d-sm-inline-block has-tooltip' , title: 'Subscribe' do
       %i.fa.fa-rss

app/views/shared/_event_filter.html.haml

+- show_group_events = local_assigns.fetch(:show_group_events, false)
+
 .scrolling-tabs-container.inner-page-scroll-tabs.is-smaller.flex-fill
   .fade-left= icon('angle-left')
   .fade-right= icon('angle-right')
@@ -9,6 +11,8 @@
       = event_filter_link EventFilter::MERGED, _('Merge events'), s_('EventFilterBy|Filter by merge events')
     - if event_filter_visible(:issues)
       = event_filter_link EventFilter::ISSUE, _('Issue events'), s_('EventFilterBy|Filter by issue events')
+    - if show_group_events
+      = render_if_exists 'events/epics_filter'
     - if comments_visible?
       = event_filter_link EventFilter::COMMENTS, _('Comments'), s_('EventFilterBy|Filter by comments')
     = event_filter_link EventFilter::TEAM, _('Team'), s_('EventFilterBy|Filter by team')

changelogs/unreleased/not_silent_retry_failure.yml

+---
+title: Stopped CRD apply retrying from allowing silent failures
+merge_request: 18421
+author:
+type: fixed

doc/administration/monitoring/prometheus/gitlab_exporter.md

 # GitLab exporter
->**Note:**
-Available since [Omnibus GitLab 8.17][1132]. For installations from source
-you'll have to install and configure it yourself.
-The [GitLab exporter] allows you to measure various GitLab metrics, pulled from Redis and the database.
-To enable the GitLab exporter:
+>- Available since [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132).
+>- Renamed from `GitLab monitor exporter` to `GitLab exporter` in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/merge_requests/16511).
+The [GitLab exporter](https://gitlab.com/gitlab-org/gitlab-exporter) allows you to
+measure various GitLab metrics, pulled from Redis and the database, in Omnibus GitLab
+instances.
+NOTE: **Note:**
+For installations from source you'll have to install and configure it yourself.
+
+To enable the GitLab exporter in an Omnibus GitLab instance:
 1. [Enable Prometheus](index.md#configuring-prometheus)
 1. Edit `/etc/gitlab/gitlab.rb`
@@ -16,15 +20,10 @@ To enable the GitLab exporter:
    gitlab_exporter['enable'] = true
    ```
-1. Save the file and [reconfigure GitLab][reconfigure] for the changes to
-   take effect
+1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure)
+   for the changes to take effect
 Prometheus will now automatically begin collecting performance data from
 the GitLab exporter exposed under `localhost:9168`.
 [← Back to the main Prometheus page](index.md)
-
-[1132]: https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1132
-[GitLab exporter]: https://gitlab.com/gitlab-org/gitlab-exporter
-[prometheus]: https://prometheus.io
-[reconfigure]: ../../restart_gitlab.md#omnibus-gitlab-reconfigure

doc/administration/monitoring/prometheus/gitlab_monitor_exporter.md

+---
+redirect_to: 'gitlab_exporter.md'
+---
+
+This document was moved to [another location](gitlab_exporter.md).

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -20,7 +20,7 @@ GitLab can run pipelines for merge requests
 on this merged result. That is, where the source and target branches are combined into a
 new ref and a pipeline for this ref validates the result prior to merging.
-![Merge request pipeline as the head pipeline](img/merge_request_pipeline.png)
+![Merge request pipeline as the head pipeline](img/merged_result_pipeline_v12_3.png)
 There are some cases where creating a combined ref is not possible or not wanted.
 For example, a source branch that has conflicts with the target branch

doc/ci/variables/predefined_variables.md

@@ -60,12 +60,12 @@ future GitLab releases.**
 | `CI_MERGE_REQUEST_PROJECT_URL`          | 11.6   | all    | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_REF_PATH`             | 11.6   | all    | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME`   | 11.6   | all    | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
-| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
+| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
 | `CI_MERGE_REQUEST_SOURCE_PROJECT_ID`    | 11.6   | all    | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH`  | 11.6   | all    | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_SOURCE_PROJECT_URL`   | 11.6   | all    | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_TARGET_BRANCH_NAME`   | 11.6   | all    | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
-| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
+| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA`    | 11.9   | all    | The HEAD SHA of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used, the merge request is created, and the pipeline is a [merged result pipeline](../merge_request_pipelines/pipelines_for_merged_results/index.md). **(PREMIUM)** |
 | `CI_MERGE_REQUEST_TITLE`                | 11.9   | all    | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |
 | `CI_MERGE_REQUEST_ASSIGNEES`            | 11.9   | all    | Comma-separated list of username(s) of assignee(s) for the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created. |
 | `CI_MERGE_REQUEST_MILESTONE`            | 11.9   | all    | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). Available only if `only: [merge_requests]` is used and the merge request is created.  |

doc/ci/yaml/README.md

@@ -3309,13 +3309,8 @@ all updated Merge Requests will have a pipeline created when using
 If your commit message contains `[ci skip]` or `[skip ci]`, using any
 capitalization, the commit will be created but the pipeline will be skipped.
-Alternatively, one can pass the `ci.skip` [Git push option][push-option] if
-using Git 2.10 or newer:
-
-```sh
-git push --push-option=ci.skip    # using git 2.10+
-git push -o ci.skip               # using git 2.18+
-```
+Alternatively, one can pass the `ci.skip` [Git push option](../../user/project/push_options.md#push-options-for-gitlab-cicd)
+if using Git 2.10 or newer.
 <!-- ## Troubleshooting

doc/development/architecture.md

@@ -12,7 +12,7 @@ Both EE and CE require some add-on components called GitLab Shell and Gitaly. Th
 ## Components
-A typical install of GitLab will be on GNU/Linux. It uses Nginx or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and a [GitLab API](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/doc/api) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses redis as a non-persistent database backend for job information, meta data, and incoming jobs.
+A typical install of GitLab will be on GNU/Linux. It uses NGINX or Apache as a web front end to proxypass the Unicorn web server. By default, communication between Unicorn and the front end is via a Unix domain socket but forwarding requests via TCP is also supported. The web front end accesses `/home/git/gitlab/public` bypassing the Unicorn server to serve static pages, uploads (e.g. avatar images or attachments), and precompiled assets. GitLab serves web pages and the [GitLab API](../api/README.md) using the Unicorn web server. It uses Sidekiq as a job queue which, in turn, uses Redis as a non-persistent database backend for job information, meta data, and incoming jobs.
 We also support deploying GitLab on Kubernetes using our [GitLab Helm chart](https://docs.gitlab.com/charts/).
@@ -20,7 +20,7 @@ The GitLab web app uses PostgreSQL for persistent database information (e.g. use
 When serving repositories over HTTP/HTTPS GitLab utilizes the GitLab API to resolve authorization and access as well as serving Git objects.
-The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
+The add-on component GitLab Shell serves repositories over SSH. It manages the SSH keys within `/home/git/.ssh/authorized_keys` which should not be manually edited. GitLab Shell accesses the bare repositories through Gitaly to serve Git objects and communicates with Redis to submit jobs to Sidekiq for GitLab to process. GitLab Shell queries the GitLab API to determine authorization and access.
 Gitaly executes Git operations from GitLab Shell and the GitLab web app, and provides an API to the GitLab web app to get attributes from Git (e.g. title, branches, tags, other meta data), and to get blobs (e.g. diffs, commits, files).
@@ -224,7 +224,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
 - Configuration: [Omnibus][geo-omnibus], [Charts][geo-charts], [GDK][geo-gdk]
 - Layer: Core Service (Processor)
-#### Gitlab Exporter
+#### GitLab Exporter
 - [Project page](https://gitlab.com/gitlab-org/gitlab-exporter)
 - Configuration: [Omnibus][gitlab-exporter-omnibus], [Charts][gitlab-exporter-charts]
@@ -258,7 +258,7 @@ GitLab CI is the open-source continuous integration service included with GitLab
 - Configuration: [Omnibus][shell-omnibus], [Charts][shell-charts], [Source][shell-source], [GDK][gitlab-yml]
 - Layer: Core Service (Processor)
-[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle ssh-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
+[GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell) is a program designed at GitLab to handle SSH-based `git` sessions, and modifies the list of authorized keys. GitLab Shell is not a Unix shell nor a replacement for Bash or Zsh.
 #### GitLab Workhorse
@@ -317,7 +317,7 @@ MinIO is an object storage server released under Apache License v2.0. It is comp
 - Layer: Core Service (Processor)
 - Process: `nginx`
-Nginx as an ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
+NGINX has an Ingress port for all HTTP requests and routes them to the appropriate sub-systems within GitLab. We are bundling an unmodified version of the popular open source webserver.
 #### Node Exporter
@@ -344,7 +344,7 @@ Lightweight connection pooler for PostgreSQL.
 Prometheus exporter for PgBouncer. Exports metrics at 9127/metrics.
-#### Postgresql
+#### PostgreSQL
 - [Project page](https://github.com/postgres/postgres/blob/master/README)
 - Configuration: [Omnibus][postgres-omnibus], [Charts][postgres-charts], [Source][postgres-source]
@@ -400,7 +400,7 @@ Redis is packaged to provide a place to store:
 - Layer: Core Service (Processor)
 The registry is what users use to store their own Docker images. The bundled
-registry uses nginx as a load balancer and GitLab as an authentication manager.
+registry uses NGINX as a load balancer and GitLab as an authentication manager.
 Whenever a client requests to pull or push an image from the registry, it will
 return a `401` response along with a header detailing where to get an
 authentication token, in this case the GitLab instance. The client will then
@@ -424,7 +424,7 @@ Sentry fundamentally is a service that helps you monitor and fix crashes in real
 - Layer: Core Service (Processor)
 - Process: `sidekiq`
-Sidekiq is a Ruby background job processor that pulls jobs from the redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
+Sidekiq is a Ruby background job processor that pulls jobs from the Redis queue and processes them. Background jobs allow GitLab to provide a faster request/response cycle by moving work into the background.
 #### Unicorn
@@ -470,9 +470,9 @@ It's important to understand the distinction as some processes are used in both
 When making a request to an HTTP Endpoint (think `/users/sign_in`) the request will take the following path through the GitLab Service:
-- nginx - Acts as our first line reverse proxy.
+- NGINX - Acts as our first line reverse proxy.
 - GitLab Workhorse - This determines if it needs to go to the Rails application or somewhere else to reduce load on Unicorn.
-- unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
+- Unicorn - Since this is a web request, and it needs to access the application it will go to Unicorn.
 - Postgres/Gitaly/Redis - Depending on the type of request, it may hit these services to store or retrieve data.
 ### GitLab Git Request Cycle
@@ -508,7 +508,7 @@ ps aux | grep '^git'
 ```
 GitLab has several components to operate. It requires a persistent database
-(PostgreSQL) and redis database, and uses Apache httpd or Nginx to proxypass
+(PostgreSQL) and Redis database, and uses Apache httpd or NGINX to proxypass
 Unicorn. All these components should run as different system users to GitLab
 (e.g., `postgres`, `redis` and `www-data`, instead of `git`).
@@ -580,7 +580,7 @@ SSH:
 - `/var/log/auth.log` auth log (on Ubuntu).
 - `/var/log/secure` auth log (on RHEL).
-nginx:
+NGINX:
 - `/var/log/nginx/` contains error and access logs.

doc/development/changelog.md

@@ -79,7 +79,7 @@ changes.
 - **Bad:** Strip out `nil`s in the Array of Commit objects returned from
   `find_commits_by_message_with_elastic`
-- **Good:** Fix 500 errors caused by elasticsearch results referencing
+- **Good:** Fix 500 errors caused by Elasticsearch results referencing
   garbage-collected commits
 The first example focuses on _how_ we fixed something, not on _what_ it fixes.

doc/development/database_debugging.md

@@ -3,7 +3,7 @@
 This section is to help give some copy-pasta you can use as a reference when you
 run into some head-banging database problems.
-An easy first step is to search for your error in Slack or google "GitLab (my error)".
+An easy first step is to search for your error in Slack, or search for `GitLab <my error>` with Google.
 ---

doc/development/documentation/improvement-workflow.md

@@ -20,7 +20,7 @@ to accomplish their work with GitLab.
 ## How to update the docs
-1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to
+1. Click "Edit this Page" at the bottom of any page on <https://docs.gitlab.com>, or navigate to
    one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page.
    Work in a fork if you do not have developer access to the GitLab project.
 1. Follow the described standards and processes listed on that Guidelines page,

doc/development/documentation/index.md

@@ -8,19 +8,18 @@ GitLab's documentation is [intended as the single source of truth (SSOT)](https:
 In addition to this page, the following resources can help you craft and contribute documentation:
-- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, and more.
+- [Style Guide](styleguide.md) - What belongs in the docs, language guidelines, Markdown standards to follow, and more.
 - [Structure and template](structure.md) - Learn the typical parts of a doc page and how to write each one.
 - [Workflows](workflow.md) - A landing page for our key workflows:
   - [Documentation process for feature changes](feature-change-workflow.md) - Adding required documentation when developing a GitLab feature.
   - [Documentation improvement workflow](improvement-workflow.md) - New content not associated with a new feature.
-- [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/) - A reference for the markdown implementation used by GitLab's documentation site and about.gitlab.com.
-- [Site architecture](site_architecture/index.md) - How docs.gitlab.com is built.
+- [Markdown Guide](../../user/markdown.md) - A reference for all markdown syntax supported by GitLab.
+- [Site architecture](site_architecture/index.md) - How <http://docs.gitlab.com> is built.
 ## Source files and rendered web locations
-Documentation for GitLab, GitLab Runner, and Omnibus is published to [docs.gitlab.com](https://docs.gitlab.com). Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
-
-At `/help`, only help for your current edition and version is included. Help for other versions is available at docs.gitlab.com.
+Documentation for GitLab, GitLab Runner, Omnibus GitLab and Charts are published to <https://docs.gitlab.com>. Documentation for GitLab is also published within the application at `/help` on the domain of the GitLab instance.
+At `/help`, only help for your current edition and version is included. Help for other versions is available at <https://docs.gitlab.com/archives/>.
 The source of the documentation exists within the codebase of each GitLab application in the following repository locations:
@@ -29,6 +28,7 @@ The source of the documentation exists within the codebase of each GitLab applic
 | [GitLab](https://gitlab.com/gitlab-org/gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
 | [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/) | [`/docs`](https://gitlab.com/gitlab-org/gitlab-runner/tree/master/docs) |
 | [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/) | [`/doc`](https://gitlab.com/gitlab-org/gitlab/tree/master/doc) |
+| [Charts](https://gitlab.com/gitlab-org/charts/gitlab) | [`/doc`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc) |
 Documentation issues and merge requests are part of their respective repositories and all have the label `Documentation`.
@@ -55,8 +55,8 @@ See the [Structure](styleguide.md#structure) section of the [Documentation Style
 Changing a document's location requires specific steps to ensure that
 users can seamlessly access the new doc page, whether they are accessing content
-on a GitLab instance domain at `/help` or at docs.gitlab.com. Be sure to ping a
-GitLab technical writer if you have any questions during the process (such as
+on a GitLab instance domain at `/help` or at <https://docs.gitlab.com>. Be sure to assign a
+technical writer if you have any questions during the process (such as
 whether the move is necessary), and ensure that a technical writer reviews this
 change prior to merging.
@@ -132,7 +132,7 @@ land on the doc via `/help`.
 If the documentation page being relocated already has Disqus comments,
 we need to preserve the Disqus thread.
-Disqus uses an identifier per page, and for docs.gitlab.com, the page identifier
+Disqus uses an identifier per page, and for <https://docs.gitlab.com>, the page identifier
 is configured to be the page URL. Therefore, when we change the document location,
 we need to preserve the old URL as the same Disqus identifier.
@@ -181,9 +181,9 @@ Every GitLab instance includes the documentation, which is available at `/help`
 (`https://gitlab.example.com/help`). For example, <https://gitlab.com/help>.
 There are [plans](https://gitlab.com/groups/gitlab-org/-/epics/693) to end this
-practice and instead link out from the GitLab application to docs.gitlab.com URLs.
-The documentation available online on docs.gitlab.com is continuously
+practice and instead link out from the GitLab application to <https://docs.gitlab.com> URLs.
+The documentation available online on <https://docs.gitlab.com> is continuously
 deployed every hour from the `master` branch of GitLab, Omnibus, and Runner. Therefore,
 once a merge request gets merged, it will be available online on the same day.
 However, they will be shipped (and available on `/help`) within the milestone assigned
@@ -195,7 +195,7 @@ available online on 2018-09-15, but, as the feature freeze date has passed, if
 the MR does not have a "pick into 11.3" label, the milestone has to be changed
 to 11.4 and it will be shipped with all GitLab packages only on 2018-10-22,
 with GitLab 11.4. Meaning, it will only be available under `/help` from GitLab
-11.4 onwards, but available on docs.gitlab.com on the same day it was merged.
+11.4 onwards, but available on <https://docs.gitlab.com/archives/> on the same day it was merged.
 ### Linking to `/help`
@@ -271,7 +271,7 @@ For example, [GitLab.com's `/help`](https://gitlab.com/help).
 ## Docs site architecture
 See the [Docs site architecture](site_architecture/index.md) page to learn
-how we build and deploy the site at [docs.gitlab.com](https://docs.gitlab.com) and
+how we build and deploy the site at <https://docs.gitlab.com> and
 to review all the assets and libraries in use.
 ### Global navigation
@@ -301,7 +301,7 @@ You will need to push a branch to those repositories, it doesn't work for forks.
 The `review-docs-deploy*` job will:
-1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-org/gitlab-docs)
+1. Create a new branch in the [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs)
    project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`,
    where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for
    CE, etc.