Add latest changes from gitlab-org/gitlab@master

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
-> [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 with merge requests
+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