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)
+    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)
+  def project_and_group_events
+    project_events = relation_with_join_lateral('project_id', projects)
+    group_events = relation_with_join_lateral('group_id', groups)
 
-    paginate_events(events)
+    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.
+>- 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] allows you to measure various GitLab metrics, pulled from Redis and the database.
+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.
 
-To enable the GitLab exporter:
+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.
+practice and instead link out from the GitLab application to <https://docs.gitlab.com> URLs.
 
-The documentation available online on docs.gitlab.com is continuously
+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.

doc/development/documentation/styleguide.md

@@ -564,7 +564,7 @@ Inside the document:
 
 ### Remove image shadow
 
-All images displayed on docs.gitlab.com have a box shadow by default.
+All images displayed on the [GitLab Docs site](https://docs.gitlab.com) have a box shadow by default.
 To remove the box shadow, use the image class `.image-noshadow` applied
 directly to an HTML `img` tag:
 
@@ -598,7 +598,7 @@ You can link any up-to-date video that is useful to the GitLab user.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-docs/merge_requests/472) in GitLab 12.1.
 
-GitLab docs (docs.gitlab.com) support embedded videos.
+The [GitLab docs site](https://docs.gitlab.com) supports embedded videos.
 
 You can only embed videos from
 [GitLab's official YouTube account](https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg).
@@ -634,7 +634,7 @@ leave a blank line here
 leave a blank line here
 ```
 
-This is how it renders on docs.gitlab.com:
+This is how it renders on the GitLab Docs site:
 
 <div class="video-fallback">
   See the video: <a href="https://www.youtube.com/watch?v=enMumwvLAug">What is GitLab</a>.
@@ -693,6 +693,10 @@ use the following markup for highlighting.
 _Note that the alert boxes only work for one paragraph only. Multiple paragraphs,
 lists, headers, etc will not render correctly. For multiple lines, use blockquotes instead._
 
+Alert boxes only render properly on the GitLab Docs site (<http://docs.gitlab.com>).
+Within GitLab itself, they will appear as plain markdown text (like the examples
+above the rendered versions, below).
+
 ### Note
 
 Notes catch the eye of most readers, and therefore should be used very sparingly.
@@ -717,7 +721,7 @@ NOTE: **Note:**
 This is something to note.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 NOTE: **Note:**
 This is something to note.
@@ -729,7 +733,7 @@ TIP: **Tip:**
 This is a tip.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 TIP: **Tip:**
 This is a tip.
@@ -741,7 +745,7 @@ CAUTION: **Caution:**
 This is something to be cautious about.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 CAUTION: **Caution:**
 This is something to be cautious about.
@@ -753,7 +757,7 @@ DANGER: **Danger:**
 This is a breaking change, a bug, or something very important to note.
 ```
 
-How it renders in docs.gitlab.com:
+How it renders on the GitLab Docs site:
 
 DANGER: **Danger:**
 This is a breaking change, a bug, or something very important to note.
@@ -766,7 +770,7 @@ For highlighting a text within a blue blockquote, use this format:
 > This is a blockquote.
 ```
 
-which renders in docs.gitlab.com to:
+which renders on the [GitLab Docs site](https://docs.gitlab.com) as:
 
 > This is a blockquote.
 
@@ -1154,7 +1158,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "title=
 ```
 
 The above example is run by and administrator and will add an SSH public key
-titled ssh-key to user's account which has an id of 25.
+titled `ssh-key` to user's account which has an id of 25.
 
 #### Escape special characters
 

doc/development/elasticsearch.md

 # Elasticsearch knowledge **(STARTER ONLY)**
 
-This area is to maintain a compendium of useful information when working with elasticsearch.
+This area is to maintain a compendium of useful information when working with Elasticsearch.
 
-Information on how to enable Elasticsearch and perform the initial indexing is kept in ../integration/elasticsearch.md#enabling-elasticsearch
+Information on how to enable Elasticsearch and perform the initial indexing is in
+the [Elasticsearch integration documentation](../integration/elasticsearch.md#enabling-elasticsearch)
 
 ## Deep Dive
 
@@ -61,7 +62,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons
 
 The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
 
-All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs).
+All indexing after the initial one is done via `ElasticIndexerWorker` (Sidekiq jobs).
 
 Search queries are generated by the concerns found in [ee/app/models/concerns/elastic](https://gitlab.com/gitlab-org/gitlab/tree/master/ee/app/models/concerns/elastic). These concerns are also in charge of access control, and have been a historic source of security bugs so please pay close attention to them!
 

doc/development/event_tracking/frontend.md

 # Frontend tracking guide
 
-GitLab provides `Tracking`, an interface that wraps the [Snowplow Javascript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
+GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilizing tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Feature instrumentation taxonomy](https://about.gitlab.com/handbook/product/feature-instrumentation/#taxonomy).
 
 | field      | type   | default value              | description |
 |:-----------|:-------|:---------------------------|:------------|
@@ -26,7 +26,7 @@ Below is an example of `data-track-*` attributes assigned to a button:
 />
 ```
 
-Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw Javascript](#tracking-in-raw-javascript).
+Event listeners are bound at the document level to handle click events on or within elements with these data attributes. This allows for them to be properly handled on rerendering and changes to the DOM, but it's important to know that because of the way these events are bound, click events shouldn't be stopped from propagating up the DOM tree. If for any reason click events are being stopped from propagating, you'll need to implement your own listeners and follow the instructions in [Tracking in raw JavaScript](#tracking-in-raw-javascript).
 
 Below is a list of supported `data-track-*` attributes:
 
@@ -99,7 +99,7 @@ And if needed within the template, you can use the `track` method directly as we
 </template>
 ```
 
-## Tracking in raw Javascript
+## Tracking in raw JavaScript
 
 Custom event tracking and instrumentation can be added by directly calling the `Tracking.event` static function. The following example demonstrates tracking a click on a button by calling `Tracking.event` manually.
 

doc/development/fe_guide/components.md

@@ -8,7 +8,7 @@
 
 See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
 
-### How to style a bootstrap dropdown
+### How to style a Bootstrap dropdown
 
 1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
 1. Add a specific class to the top level `.dropdown` element

doc/development/fe_guide/development_process.md

@@ -80,7 +80,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
 
 1. Before writing code, ensure your vision of the architecture is aligned with
    GitLab's architecture.
-1. Add a diagram to the issue and ask a frontend maintainer in the slack channel `#frontend_maintainers` about it.
+1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.
 
    ![Diagram of Issue Boards Architecture](img/boards_diagram.png)
 

doc/development/fe_guide/icons.md

 # Icons and SVG Illustrations
 
-We manage our own Icon and Illustration library in the [gitlab-svgs][gitlab-svgs] repository.
+We manage our own Icon and Illustration library in the [`gitlab-svgs`][gitlab-svgs] repository.
 This repository is published on [npm][npm] and managed as a dependency via yarn.
 You can browse all available Icons and Illustrations [here][svg-preview].
 To upgrade to a new version run `yarn upgrade @gitlab/svgs`.

doc/development/fe_guide/performance.md

@@ -65,26 +65,27 @@ within the `pages` directory correspond to Rails controllers and actions. These
 auto-generated bundles will be automatically included on the corresponding
 pages.
 
-For example, if you were to visit [gitlab.com/gitlab-org/gitlab-foss/issues](https://gitlab.com/gitlab-org/gitlab-foss/issues),
+For example, if you were to visit <https://gitlab.com/gitlab-org/gitlab/issues>,
 you would be accessing the `app/controllers/projects/issues_controller.rb`
 controller with the `index` action. If a corresponding file exists at
 `pages/projects/issues/index/index.js`, it will be compiled into a webpack
 bundle and included on the page.
 
-> **Note:** Previously we had encouraged the use of
-> `content_for :page_specific_javascripts` within haml files, along with
-> manually generated webpack bundles. However under this new system you should
-> not ever need to manually add an entry point to the `webpack.config.js` file.
->
-> **Tip:**
-> If you are unsure what controller and action corresponds to a given page, you
-> can find this out by inspecting `document.body.dataset.page` within your
-> browser's developer console while on any page within gitlab.
+NOTE: **Note:**
+Previously we had encouraged the use of
+`content_for :page_specific_javascripts` within haml files, along with
+manually generated webpack bundles. However under this new system you should
+not ever need to manually add an entry point to the `webpack.config.js` file.
+
+TIP: **Tip:**
+If you are unsure what controller and action corresponds to a given page, you
+can find this out by inspecting `document.body.dataset.page` within your
+browser's developer console while on any page within GitLab.
 
 #### Important Considerations
 
 - **Keep Entry Points Lite:**
-  Page-specific javascript entry points should be as lite as possible.  These
+  Page-specific JavaScript entry points should be as lite as possible.  These
   files are exempt from unit tests, and should be used primarily for
   instantiation and dependency injection of classes and methods that live in
   modules outside of the entry point script.  Just import, read the DOM,

doc/development/fe_guide/security.md

@@ -63,7 +63,7 @@ External fonts, CSS, and JavaScript should never be used with the exception of
 Google Analytics and Piwik - and only when the instance has enabled it. Assets
 should always be hosted and served locally from the GitLab instance. Embedded
 resources via `iframes` should never be used except in certain circumstances
-such as with ReCaptcha, which cannot be used without an `iframe`.
+such as with reCAPTCHA, which cannot be used without an `iframe`.
 
 ## Avoiding inline scripts and styles
 

doc/development/fe_guide/style_guide_js.md

@@ -287,7 +287,7 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab/blob/master/.es
 
 #### CSS classes used for JavaScript
 
-1. If the class is being used in Javascript it needs to be prepend with `js-`
+1. If the class is being used in JavaScript it needs to be prepend with `js-`
 
    ```html
    // bad
@@ -693,7 +693,7 @@ Useful links:
    $('span').tooltip('_fixTitle');
    ```
 
-### The Javascript/Vue Accord
+### The JavaScript/Vue Accord
 
 The goal of this accord is to make sure we are all on the same page.
 

doc/development/feature_flags/controls.md

@@ -3,7 +3,7 @@
 In order to be able to turn on/off features behind feature flags in any of the
 GitLab Inc. provided environments such as staging and production, you need to
 have access to the chatops bot. Chatops bot is currently running on the ops instance,
-which is different from GitLab.com or dev.gitlab.org.
+which is different from <https://gitlab.com> or <https://dev.gitlab.org>.
 
 Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#requesting-access).
 
@@ -39,7 +39,7 @@ If you get an error "Whoops! This action is not allowed. This incident
 will be reported." that means your Slack account is not allowed to
 change feature flags or you do not [have access](#access-for-enabling-a-feature-flag-in-production).
 
-### Enabling feature for staging and dev.gitlab.org
+### Enabling feature for internal testing
 
 As a first step in a feature rollout, you should enable the feature on <https://staging.gitlab.com>
 and <https://dev.gitlab.org>.

doc/development/gitaly.md

@@ -15,9 +15,9 @@ In May 2019, Bob Van Landuyt hosted a [Deep Dive] on GitLab's [Gitaly project] a
 
 ## Beginner's guide
 
-Start by reading the gitaly repository's
+Start by reading the Gitaly repository's
 [Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/beginners_guide.md).
-It describes how to setup gitaly, the various components of gitaly and what they do, and how to run its test suites.
+It describes how to setup Gitaly, the various components of Gitaly and what they do, and how to run its test suites.
 
 ## Developing new Git features
 
@@ -41,14 +41,14 @@ disk access (e.g. Rugged, `git`, `rm -rf`) anywhere outside
 The process for adding new Gitaly features is:
 
 - exploration / prototyping
-- design and create a new Gitaly RPC [in gitaly-proto](https://gitlab.com/gitlab-org/gitaly-proto)
-- release a new version of gitaly-proto
+- design and create a new Gitaly RPC in [`gitaly-proto`](https://gitlab.com/gitlab-org/gitaly-proto)
+- release a new version of `gitaly-proto`
 - write implementation and tests for the RPC [in Gitaly](https://gitlab.com/gitlab-org/gitaly), in Go or Ruby
 - release a new version of Gitaly
 - write client code in GitLab CE/EE, GitLab Workhorse or GitLab Shell that calls the new Gitaly RPC
 
 These steps often overlap. It is possible to use an unreleased version
-of Gitaly and gitaly-proto during testing and development.
+of Gitaly and `gitaly-proto` during testing and development.
 
 - See the [Gitaly repo](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
 - See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
@@ -58,7 +58,7 @@ of Gitaly and gitaly-proto during testing and development.
 
 It is possible to implement and test RPC's in Gitaly using Ruby code,
 in
-[gitaly-ruby](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
+[`gitaly-ruby`](https://gitlab.com/gitlab-org/gitaly/tree/master/ruby).
 This should make it easier to contribute for developers who are less
 comfortable writing Go code.
 
@@ -234,7 +234,7 @@ Here are the steps to gate a new feature in Gitaly behind a feature flag.
    }
    ```
 
-1. Create prometheus metrics:
+1. Create Prometheus metrics:
 
    ```go
    var findAllTagsRequests = prometheus.NewCounterVec(

doc/development/i18n/index.md

@@ -29,7 +29,7 @@ See [Externalization for GitLab](externalization.md).
 
 ### Translate strings
 
-The translation process is managed at [translate.gitlab.com](https://translate.gitlab.com)
+The translation process is managed at <https://translate.gitlab.com>
 using [Crowdin](https://crowdin.com/).
 You will need to create an account before you can submit translations.
 Once you are signed in, select the language you wish to contribute translations to.

doc/development/i18n/proofreader.md

@@ -57,7 +57,7 @@ are very appreciative of the work done by translators and proofreaders!
   - Paolo Falomo - [GitLab](https://gitlab.com/paolofalomo), [Crowdin](https://crowdin.com/profile/paolo.falomo)
 - Japanese
   - Hiroyuki Sato - [GitLab](https://gitlab.com/hiroponz), [Crowdin](https://crowdin.com/profile/hiroponz)
-  - Tomo Dote - [Gitlab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
+  - Tomo Dote - [GitLab](https://gitlab.com/fu7mu4), [Crowdin](https://crowdin.com/profile/fu7mu4)
 - Korean
   - Chang-Ho Cha - [GitLab](https://gitlab.com/changho-cha), [Crowdin](https://crowdin.com/profile/zzazang)
   - Ji Hun Oh - [GitLab](https://gitlab.com/Baw-Appie), [Crowdin](https://crowdin.com/profile/BawAppie)

doc/development/i18n/translation.md

@@ -8,7 +8,7 @@ The first step is to get familiar with Crowdin.
 
 ### Sign In
 
-To contribute translations at [translate.gitlab.com](https://translate.gitlab.com)
+To contribute translations at <https://translate.gitlab.com>
 you must create a Crowdin account.
 You may create a new account or use any of their supported sign in services.
 
@@ -54,7 +54,7 @@ For example in French `OpenedNDaysAgo|Opened` would be translated to
 Some technical terms should be treated like proper nouns and not be translated.
 
 Technical terms that should always be in English are noted in the glossary when
-using [translate.gitlab.com](https://translate.gitlab.com).
+using <https://translate.gitlab.com>.
 
 This helps maintain a logical connection and consistency between tools (e.g.
 `git` client) and GitLab.

doc/development/import_export.md

@@ -36,7 +36,7 @@ SIDEKIQ_MEMORY_KILLER_HARD_LIMIT_RSS = 3000000
 SIDEKIQ_MEMORY_KILLER_GRACE_TIME = 900
 ```
 
-An import status `started`, and the following sidekiq logs will signal a memory issue:
+An import status `started`, and the following Sidekiq logs will signal a memory issue:
 
 ```bash
 WARN: Work still in progress <struct with JID>

doc/development/interacting_components.md

@@ -14,7 +14,7 @@ change that affects uploads should also be tested against [object storage],
 which is _not_ enabled by default in [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit).
 
 When working on a related feature, make sure to enable and test it
-against [Minio](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
+against [MinIO](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/object_storage.md).
 
 See also [File Storage in GitLab](file_storage.md).
 

doc/development/kubernetes.md

@@ -44,12 +44,11 @@ to the relevant internal client.
 
 All calls to the Kubernetes API must be in a background process. Do not
 perform Kubernetes API calls within a web request as this will block
-unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
+Unicorn and can easily lead to a Denial Of Service (DoS) attack in GitLab as
 the Kubernetes cluster response times are outside of our control.
 
 The easiest way to ensure your calls happen a background process is to
-delegate any such work to happen in a [sidekiq
-worker](sidekiq_style_guide.md).
+delegate any such work to happen in a [Sidekiq worker](sidekiq_style_guide.md).
 
 There are instances where you would like to make calls to Kubernetes and
 return the response and as such a background worker does not seem to be

doc/development/new_fe_guide/development/components.md

@@ -7,7 +7,7 @@ We have a lot of graphing libraries in our codebase to render graphs. In an effo
 We chose D3 as our library going forward because of the following features:
 
 - [Tree shaking webpack capabilities](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
-- [Compatible with vue.js as well as vanilla javascript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
+- [Compatible with vue.js as well as vanilla JavaScript](https://github.com/d3/d3/blob/master/CHANGES.md#changes-in-d3-40).
 
 D3 is very popular across many projects outside of GitLab:
 

doc/development/new_fe_guide/development/performance.md

@@ -2,9 +2,9 @@
 
 ## Monitoring
 
-We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
+We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
-These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
+These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
 Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
 
 There are 3 recommended high impact metrics to review on each page:

doc/development/sidekiq_style_guide.md

@@ -27,7 +27,7 @@ While different workers cannot share a queue, they can share a queue namespace.
 Defining a queue namespace for a worker makes it possible to start a Sidekiq
 process that automatically handles jobs for all workers in that namespace,
 without needing to explicitly list all their queue names. If, for example, all
-workers that are managed by sidekiq-cron use the `cronjob` queue namespace, we
+workers that are managed by `sidekiq-cron` use the `cronjob` queue namespace, we
 can spin up a Sidekiq process specifically for these kinds of scheduled jobs.
 If a new worker using the `cronjob` namespace is added later on, the Sidekiq
 process will automatically pick up jobs for that worker too (after having been

doc/development/testing_guide/best_practices.md

@@ -113,7 +113,7 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load)
 1 example, 0 failures
 ```
 
-Note: `live_debug` only works on javascript enabled specs.
+Note: `live_debug` only works on JavaScript enabled specs.
 
 #### Run `:js` spec in a visible browser
 
@@ -158,7 +158,7 @@ really fast since:
 
 - Gems loading is skipped
 - Rails app boot is skipped
-- gitlab-shell and Gitaly setup are skipped
+- GitLab Shell and Gitaly setup are skipped
 - Test repositories setup are skipped
 
 `fast_spec_helper` also support autoloading classes that are located inside the
@@ -347,7 +347,7 @@ them unspecified, and look up the value after the row is created.
 
 #### Redis
 
-GitLab stores two main categories of data in Redis: cached items, and sidekiq
+GitLab stores two main categories of data in Redis: cached items, and Sidekiq
 jobs.
 
 In most specs, the Rails cache is actually an in-memory store. This is replaced
@@ -587,9 +587,9 @@ All fixtures should be placed under `spec/fixtures/`.
 
 ### Repositories
 
-Testing some functionality, e.g., merging a merge request, requires a git
+Testing some functionality, e.g., merging a merge request, requires a Git
 repository with a certain state to be present in the test environment. GitLab
-maintains the [gitlab-test](https://gitlab.com/gitlab-org/gitlab-test)
+maintains the [`gitlab-test`](https://gitlab.com/gitlab-org/gitlab-test)
 repository for certain common cases - you can ensure a copy of the repository is
 used with the `:repository` trait for project factories:
 

doc/development/testing_guide/end_to_end/page_objects.md

@@ -2,7 +2,7 @@
 
 In GitLab QA we are using a known pattern, called _Page Objects_.
 
-This means that we have built an abstraction for all GitLab pages that we use
+This means that we have built an abstraction for all pages in GitLab that we use
 to drive GitLab QA scenarios. Whenever we do something on a page, like filling
 in a form, or clicking a button, we do that only through a page object
 associated with this area of GitLab.

doc/development/testing_guide/flaky_tests.md

@@ -61,7 +61,7 @@ This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/m
   - [Capybara.reset_session! should be called before requests are blocked](https://gitlab.com/gitlab-org/gitlab-foss/issues/33779): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/12224>
 - FFaker generates funky data that tests are not ready to handle (and tests should be predictable so that's bad!):
   - [Make `spec/mailers/notify_spec.rb` more robust](https://gitlab.com/gitlab-org/gitlab-foss/issues/20121): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10015>
-  - [Transient failure in spec/requests/api/commits_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
+  - [Transient failure in `spec/requests/api/commits_spec.rb`](https://gitlab.com/gitlab-org/gitlab-foss/issues/27988#note_25342521): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/9944>
   - [Replace FFaker factory data with sequences](https://gitlab.com/gitlab-org/gitlab-foss/issues/29643): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10184>
   - [Transient failure in spec/finders/issues_finder_spec.rb](https://gitlab.com/gitlab-org/gitlab-foss/issues/30211#note_26707685): <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/10404>
 

doc/development/testing_guide/frontend_testing.md

@@ -482,7 +482,7 @@ As long as the fixtures don't change, `yarn test` is sufficient (and saves you s
 
 While developing locally, it may be helpful to keep Karma running so that you
 can get instant feedback on as you write tests and modify code. To do this
-you can start Karma with `yarn run karma-start`. It will compile the javascript
+you can start Karma with `yarn run karma-start`. It will compile the JavaScript
 assets and run a server at `http://localhost:9876/` where it will automatically
 run the tests on any browser which connects to it. You can enter that url on
 multiple browsers at once to have it run the tests on each in parallel.

doc/development/testing_guide/review_apps.md

@@ -142,7 +142,7 @@ their node under pressure.
 ### Log into my Review App
 
 The default username is `root` and its password can be found in the 1Password
-secure note named **gitlab-{ce,ee} Review App's root password**.
+secure note named `gitlab-{ce,ee} Review App's root password`.
 
 ### Enable a feature flag for my Review App
 
@@ -235,7 +235,7 @@ For the record, the debugging steps to find out this issue were:
 1. Switch kubectl context to review-apps-ce (we recommend using [kubectx](https://github.com/ahmetb/kubectx/))
 1. `kubectl get pods | grep dns`
 1. `kubectl describe pod <pod name>` & confirm exact error message
-1. Web search for exact error message, following rabbit hole to [a relevant kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
+1. Web search for exact error message, following rabbit hole to [a relevant Kubernetes bug report](https://github.com/kubernetes/kubernetes/issues/57345)
 1. Access the node over SSH via the GCP console (**Computer Engine > VM
    instances** then click the "SSH" button for the node where the `dns-gitlab-review-app-external-dns` pod runs)
 1. In the node: `systemctl --version` => systemd 232

doc/development/uploads.md

@@ -82,7 +82,7 @@ To address this problem an HA object storage can be used and it's supported by [
 
 Scaling NFS is outside of our support scope, and NFS is not a part of cloud native installations.
 
-All features that require sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since sidekiq POD cannot reach into other pods, the operation will fail to read it.
+All features that require Sidekiq and do not use object storage acceleration won't work without NFS. In Kubernetes, machine boundaries translate to PODs, and in this case the uploaded file will be written into the POD private disk. Since Sidekiq POD cannot reach into other pods, the operation will fail to read it.
 
 ## How to select the proper level of acceleration?
 
@@ -92,19 +92,19 @@ We can identify three major use-cases for an upload:
 
 1. **storage:** if we are uploading for storing a file (i.e. artifacts, packages, discussion attachments). In this case [object storage acceleration](#workhorse-object-storage-acceleration) is the proper level as it's the less resource-intensive operation. Additional information can be found on [File Storage in GitLab](file_storage.md).
 1. **in-controller/synchronous processing:** if we allow processing **small files** synchronously, using [disk acceleration](#workhorse-disk-acceleration) may speed up development.
-1. **sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
+1. **Sidekiq/asynchronous processing:** Async processing must implement [object storage acceleration](#workhorse-object-storage-acceleration), the reason being that it's the only way to support Cloud Native deployments without a shared NFS.
 
 For more details about currently broken feature see [epic &1802](https://gitlab.com/groups/gitlab-org/-/epics/1802).
 
 ### Handling repository uploads
 
-Some features involves git repository uploads without using a regular git client.
+Some features involves Git repository uploads without using a regular Git client.
 Some examples are uploading a repository file from the web interface and [design management](../user/project/issues/design_management.md).
 
-Those uploads requires the rails controller to act as a git client in lieu of the user.
+Those uploads requires the rails controller to act as a Git client in lieu of the user.
 Those operation falls into _in-controller/synchronous processing_ category, but we have no warranties on the file size.
 
-In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with sidekiq.
+In case of a LFS upload, the file pointer is committed synchronously, but file upload to object storage is performed asynchronously with Sidekiq.
 
 ## Upload encodings
 
@@ -114,7 +114,7 @@ We have three kinds of file encoding in our uploads:
 
 1. <i class="fa fa-check-circle"></i> **multipart**: `multipart/form-data` is the most common, a file is encoded as a part of a multipart encoded request.
 1. <i class="fa fa-check-circle"></i> **body**: some APIs uploads files as the whole request body.
-1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This requires [gitlab-workhorse#226](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226) to be implemented.
+1. <i class="fa fa-times-circle"></i> **JSON**: some JSON API uploads files as base64 encoded strings. This will require a change to GitLab Workhorse, which [is planned](https://gitlab.com/gitlab-org/gitlab-workhorse/issues/226).
 
 ## Uploading technologies
 
@@ -212,7 +212,9 @@ In this setup an extra rails route needs to be implemented in order to handle au
 you can see an example of this in [`Projects::LfsStorageController`](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/app/controllers/projects/lfs_storage_controller.rb)
 and [its routes](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/config/routes/git_http.rb#L31-32).
 
-**note:** this will fallback to _Workhorse disk acceleration_ when object storage is not enabled in the gitlab instance. The answer to the `/authorize` call will only contain a file system path.
+NOTE: **Note:**
+This will fall back to _Workhorse disk acceleration_ when object storage is not enabled
+in the GitLab instance. The answer to the `/authorize` call will only contain a file system path.
 
 ```mermaid
 sequenceDiagram
@@ -267,4 +269,4 @@ sequenceDiagram
 
 This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled.
 
-Once the request reachs rails, it will schedule an object storage upload as a sidekiq job.
+Once the request reachs rails, it will schedule an object storage upload as a Sidekiq job.

doc/user/project/deploy_tokens/index.md

@@ -71,7 +71,7 @@ To read the container registry images, you'll need to:
 1. Log in to GitLab’s Container Registry using the deploy token:
 
 ```sh
-docker login registry.example.com -u <username> -p <deploy_token>
+docker login -u <username> -p <deploy_token> registry.example.com
 ```
 
 Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply

doc/user/project/merge_requests/index.md

@@ -290,140 +290,10 @@ apply the patches. The target branch can be specified using the
 [`/target_branch` quick action](../quick_actions.md). If the source
 branch already exists, the patches will be applied on top of it.
 
-## Git push options
+## Use Git push options with merge requests
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) in GitLab 11.10.
-
-NOTE: **Note:**
-Git push options are only available with Git 2.10 or newer. With Git older than 2.18
-`git push --push-option=...` should be used instead of `git push -o ...`.
-
-GitLab supports using
-[Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt)
-to perform the following actions against merge requests at the same time
-as pushing changes:
-
-- Create a new merge request for the pushed branch.
-- Set the target of the merge request to a particular branch.
-- Set the merge request to merge when its pipeline succeeds.
-- Set the merge request to remove the source branch when it's merged.
-- Set the title of the merge request to a particular title.
-- Set the description of the merge request to a particular description.
-- Add or remove labels from the merge request.
-
-### Create a new merge request using Git push options
-
-To create a new merge request for a branch, use the
-`merge_request.create` push option:
-
-```sh
-git push -o merge_request.create
-```
-
-### Set the target branch of a merge request using Git push options
-
-To update an existing merge request's target branch, use the
-`merge_request.target=<branch_name>` push option:
-
-```sh
-git push -o merge_request.target=branch_name
-```
-
-You can also create a merge request and set its target branch at the
-same time using a `-o` flag per push option:
-
-```sh
-git push -o merge_request.create -o merge_request.target=branch_name
-```
-
-### Set merge when pipeline succeeds using Git push options
-
-To set an existing merge request to
-[merge when its pipeline succeeds](merge_when_pipeline_succeeds.md), use
-the `merge_request.merge_when_pipeline_succeeds` push option:
-
-```sh
-git push -o merge_request.merge_when_pipeline_succeeds
-```
-
-You can also create a merge request and set it to merge when its
-pipeline succeeds at the same time using a `-o` flag per push option:
-
-```sh
-git push -o merge_request.create -o merge_request.merge_when_pipeline_succeeds
-```
-
-### Set removing the source branch using Git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
-
-To set an existing merge request to remove the source branch when the
-merge request is merged, the
-`merge_request.remove_source_branch` push option can be used:
-
-```sh
-git push -o merge_request.remove_source_branch
-```
-
-You can also use this push option in addition to the
-`merge_request.create` push option.
-
-### Set merge request title using Git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
-
-To set the title of an existing merge request, use
-the `merge_request.title` push option:
-
-```sh
-git push -o merge_request.title="The title I want"
-```
-
-You can also use this push option in addition to the
-`merge_request.create` push option.
-
-### Set merge request description using Git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320) in GitLab 12.2.
-
-To set the description of an existing merge request, use
-the `merge_request.description` push option:
-
-```sh
-git push -o merge_request.description="The description I want"
-```
-
-You can also use this push option in addition to the
-`merge_request.create` push option.
-
-### Add or remove labels using Git push options
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) in GitLab 12.3.
-
-You can add or remove labels from merge requests using push options.
-
-For example, to add two labels to an existing merge request, use the
-`merge_request.label` push option:
-
-```sh
-git push -o merge_request.label="label1" -o merge_request.label="label2"
-```
-
-To remove two labels from an existing merge request, use
-the `merge_request.unlabel` push option:
-
-```sh
-git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"
-```
-
-You can also use these push options in addition to the
-`merge_request.create` push option.
-
-To create a merge request and add two labels to it, use:
-
-```sh
-git push -o merge_request.create -o merge_request.label="label1" -o merge_request.label="label2"
-```
+Use [Git push options](../push_options.md) to create or update merge requests when
+pushing changes to GitLab with Git, without needing to use the GitLab interface.
 
 ## Find the merge request that introduced a change
 

doc/user/project/merge_requests/merge_request_approvals.md

@@ -66,13 +66,7 @@ suitable to your workflow:
 
 ## Editing approvals **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
-
-CAUTION: **Caution:**
-There was a [regression affecting this feature in 11.8](https://gitlab.com/gitlab-org/gitlab/merge_requests/9648). We recommend upgrading _at least_ to version 11.8.2. to avoid any issues.
-
-NOTE: **Note:**
-In 11.8 this feature does not work in [private groups](https://gitlab.com/gitlab-org/gitlab/issues/10356).
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 
 For GitLab Premium, [multiple approver rules](#multiple-approval-rules-premium) can be configured. To configure the merge
 request approval rules:
@@ -87,7 +81,7 @@ request approval rules:
 
 ## Multiple approval rules **(PREMIUM)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
 
 For GitLab Premium, a merge request's overall approval status is determined by a set of rules. Each rule contains:
 

doc/user/project/push_options.md

+---
+type: reference
+---
+
+# Push Options
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/15643) in GitLab 11.7.
+
+GitLab supports using [Git push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt)
+to perform various actions at the same time as pushing changes.
+
+Currently, there are push options available for:
+
+- [Skipping CI jobs](#push-options-for-gitlab-cicd)
+- [Merge requests](#push-options-for-merge-requests)
+
+NOTE: **Note:**
+Git push options are only available with Git 2.10 or newer.
+
+For Git versions 2.10 to 2.17 use `--push-option`:
+
+```shell
+git push --push-option=<push_option>
+```
+
+For version 2.18 and later, you can use the above format, or the shorter `-o`:
+
+```shell
+git push -o <push_option>
+```
+
+## Push options for GitLab CI/CD
+
+If the `ci.skip` push option is used, the commit will be pushed, but no [CI pipeline](../../ci/pipelines.md)
+will be created.
+
+| Push option | Description |
+| ----------- | ----------- |
+| `ci.skip`   | Do not create a CI pipeline for the latest push. |
+
+For example:
+
+```shell
+git push -o ci.skip
+```
+
+## Push options for merge requests
+
+You can use Git push options to perform certain actions for merge requests at the same
+time as pushing changes:
+
+| Push option                                  | Description                                                                                                     | Introduced in version |
+| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------------- |
+| `merge_request.create`                       | Create a new merge request for the pushed branch.                                                               | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
+| `merge_request.target=<branch_name>`         | Set the target of the merge request to a particular branch.                                                     | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
+| `merge_request.merge_when_pipeline_succeeds` | Set the merge request to [merge when its pipeline succeeds](merge_requests/merge_when_pipeline_succeeds.md).    | [11.10](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/26752) |
+| `merge_request.remove_source_branch`         | Set the merge request to remove the source branch when it's merged.                                             | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320)          |
+| `merge_request.title="<title>"`              | Set the title of the merge request. Ex: `git push -o merge_request.title="The title I want"`.                   | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320)          |
+| `merge_request.description="<description>"`  | Set the description of the merge request. Ex: `git push -o merge_request.description="The description I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/issues/64320)          |
+| `merge_request.label="<label>"`              | Add labels to the merge request. If the label does not exist, it will be created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) |
+| `merge_request.unlabel="<label>"`            | Remove labels from the merge request. For example, for two labels: `git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31831) |
+
+If you use a push option that requires text with spaces in it, you need to enclose it
+in quotes (`"`). You can omit the quotes if there are no spaces. Some examples:
+
+```shell
+git push -o merge_request.label="Label with spaces"
+git push -o merge_request.label=Label-with-no-spaces
+```
+
+You can combine push options to accomplish multiple tasks at once, by using
+multiple `-o` (or `--push-option`) flags. For example, if you want to create a new
+merge request, and target a branch named `my-target-branch`:
+
+```shell
+git push -o merge_request.create -o merge_request.target=my-target-branch
+```

lib/event_filter.rb

@@ -9,12 +9,11 @@ class EventFilter
   ISSUE = 'issue'
   COMMENTS = 'comments'
   TEAM = 'team'
-  FILTERS = [ALL, PUSH, MERGED, ISSUE, COMMENTS, TEAM].freeze
 
   def initialize(filter)
     # Split using comma to maintain backward compatibility Ex/ "filter1,filter2"
     filter = filter.to_s.split(',')[0].to_s
-    @filter = FILTERS.include?(filter) ? filter : ALL
+    @filter = filters.include?(filter) ? filter : ALL
   end
 
   def active?(key)
@@ -39,4 +38,12 @@ class EventFilter
     end
   end
   # rubocop: enable CodeReuse/ActiveRecord
+
+  private
+
+  def filters
+    [ALL, PUSH, MERGED, ISSUE, COMMENTS, TEAM]
+  end
 end
+
+EventFilter.prepend_if_ee('EE::EventFilter')

lib/gitlab/database.rb

@@ -87,10 +87,6 @@ module Gitlab
       version.to_f < 10
     end
 
-    def self.join_lateral_supported?
-      version.to_f >= 9.3
-    end
-
     def self.replication_slots_supported?
       version.to_f >= 9.4
     end

lib/gitlab/kubernetes/helm/client_command.rb

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

locale/gitlab.pot

@@ -6162,6 +6162,9 @@ msgstr ""
 msgid "Epic"
 msgstr ""
 
+msgid "Epic events"
+msgstr ""
+
 msgid "Epics"
 msgstr ""
 
@@ -6435,6 +6438,9 @@ msgstr ""
 msgid "EventFilterBy|Filter by comments"
 msgstr ""
 
+msgid "EventFilterBy|Filter by epic events"
+msgstr ""
+
 msgid "EventFilterBy|Filter by issue events"
 msgstr ""
 

scripts/lint-doc.sh

@@ -24,12 +24,12 @@ then
 fi
 
 # Make sure no files in doc/ are executable
-EXEC_PERM_COUNT=$(find doc/ app/ -type f -perm 755 | wc -l)
+EXEC_PERM_COUNT=$(find doc/ -type f -perm 755 | wc -l)
 echo '=> Checking for executable permissions...'
 if [ "${EXEC_PERM_COUNT}" -ne 0 ]
 then
   echo '✖ ERROR: Executable permissions should not be used in documentation! Use `chmod 644` to the files in question:' >&2
-  find doc/ app/ -type f -perm 755
+  find doc/ -type f -perm 755
   exit 1
 fi
 

spec/controllers/groups_controller_spec.rb

@@ -125,7 +125,7 @@ describe GroupsController do
     end
 
     context 'as json' do
-      it 'includes all projects from groups and subgroups in event feed' do
+      it 'includes events from all projects in group and subgroups' do
         2.times do
           project = create(:project, group: group)
           create(:event, project: project)

spec/features/projects/features_visibility_spec.rb

@@ -211,7 +211,7 @@ describe 'Edit Project Settings' do
       visit activity_project_path(project)
 
       page.within(".event-filter") do
-        expect(page).to have_selector("a", count: 2)
+        expect(page).to have_content("All")
         expect(page).not_to have_content("Push events")
         expect(page).not_to have_content("Merge events")
         expect(page).not_to have_content("Comments")

spec/lib/event_filter_spec.rb

@@ -3,12 +3,6 @@
 require 'spec_helper'
 
 describe EventFilter do
-  describe 'FILTERS' do
-    it 'returns a definite list of filters' do
-      expect(described_class::FILTERS).to eq(%w[all push merged issue comments team])
-    end
-  end
-
   describe '#filter' do
     it 'returns "all" if given filter is nil' do
       expect(described_class.new(nil).filter).to eq(described_class::ALL)

spec/lib/gitlab/database_spec.rb

@@ -101,20 +101,6 @@ describe Gitlab::Database do
     end
   end
 
-  describe '.join_lateral_supported?' do
-    it 'returns false when using PostgreSQL 9.2' do
-      allow(described_class).to receive(:version).and_return('9.2.1')
-
-      expect(described_class.join_lateral_supported?).to eq(false)
-    end
-
-    it 'returns true when using PostgreSQL 9.3.0 or newer' do
-      allow(described_class).to receive(:version).and_return('9.3.0')
-
-      expect(described_class.join_lateral_supported?).to eq(true)
-    end
-  end
-
   describe '.replication_slots_supported?' do
     it 'returns false when using PostgreSQL 9.3' do
       allow(described_class).to receive(:version).and_return('9.3.1')

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)..."; done
+      for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
       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)..."; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
         #{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)..."; done
+      for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
       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)..."; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
         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)..."; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
         #{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)..."; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
         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)..."; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
         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)..."; done
+        for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
         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)..."; done
+        for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
         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)..."; done'
+        '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'
       ])
     end
 

spec/models/event_collection_spec.rb

@@ -4,10 +4,12 @@ require 'spec_helper'
 
 describe EventCollection do
   describe '#to_a' do
-    let(:project) { create(:project_empty_repo) }
-    let(:projects) { Project.where(id: project.id) }
-    let(:user) { create(:user) }
+    set(:group) { create(:group) }
+    set(:project) { create(:project_empty_repo, group: group) }
+    set(:projects) { Project.where(id: project.id) }
+    set(:user) { create(:user) }
 
+    context 'with project events' do
       before do
         20.times do
           event = create(:push_event, project: project, author: user)
@@ -50,4 +52,27 @@ describe EventCollection do
         expect(events[0].action).to eq(Event::CLOSED)
       end
     end
+
+    context 'with group events' do
+      let(:groups) { group.self_and_descendants.public_or_visible_to_user(user) }
+      let(:subject) { described_class.new(projects, groups: groups).to_a }
+
+      it 'includes also group events' do
+        subgroup = create(:group, parent: group)
+        event1 = create(:event, project: project, author: user)
+        event2 = create(:event, project: nil, group: group, author: user)
+        event3 = create(:event, project: nil, group: subgroup, author: user)
+
+        expect(subject).to eq([event3, event2, event1])
+      end
+
+      it 'does not include events from inaccessible groups' do
+        subgroup = create(:group, :private, parent: group)
+        event1 = create(:event, project: nil, group: group, author: user)
+        create(:event, project: nil, group: subgroup, author: user)
+
+        expect(subject).to eq([event1])
+      end
+    end
+  end
 end