Add latest changes from gitlab-org/gitlab@master

17 files changed, 161 insertions, 76 deletions

diff --git a/app/assets/javascripts/issue_show/components/description.vue b/app/assets/javascripts/issue_show/components/description.vue
index 0812392f804..4c6a1478e95 100644
--- a/app/assets/javascripts/issue_show/components/description.vue
+++ b/app/assets/javascripts/issue_show/components/description.vue
@@ -123,6 +123,7 @@ export default {
       }
     },
   },
+  safeHtmlConfig: { ADD_TAGS: ['gl-emoji'] },
 };
 </script>
 
@@ -136,7 +137,7 @@ export default {
   >
     <div
       ref="gfm-content"
-      v-safe-html="descriptionHtml"
+      v-safe-html:[$options.safeHtmlConfig]="descriptionHtml"
       :class="{
         'issue-realtime-pre-pulse': preAnimation,
         'issue-realtime-trigger-pulse': pulseAnimation,
diff --git a/app/assets/javascripts/lib/dompurify.js b/app/assets/javascripts/lib/dompurify.js
index ff512364356..d421d66981e 100644
--- a/app/assets/javascripts/lib/dompurify.js
+++ b/app/assets/javascripts/lib/dompurify.js
@@ -3,7 +3,7 @@ import { getBaseURL, relativePathToAbsolute } from '~/lib/utils/url_utility';
 
 const defaultConfig = {
   // Safely allow SVG <use> tags
-  ADD_TAGS: ['use'],
+  ADD_TAGS: ['use', 'gl-emoji'],
   // Prevent possible XSS attacks with data-* attributes used by @rails/ujs
   // See https://gitlab.com/gitlab-org/gitlab-ui/-/issues/1421
   FORBID_ATTR: ['data-remote', 'data-url', 'data-type', 'data-method'],
diff --git a/app/assets/stylesheets/pages/note_form.scss b/app/assets/stylesheets/pages/note_form.scss
index 34a03a07405..3c0f10eb5cb 100644
--- a/app/assets/stylesheets/pages/note_form.scss
+++ b/app/assets/stylesheets/pages/note_form.scss
@@ -37,7 +37,7 @@
 
 .note-textarea {
   display: block;
-  padding: 10px 0;
+  padding: 10px 1px;
   color: $gl-text-color;
   font-family: $regular-font;
   border: 0;
diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md
index 8a0badbdd63..c93a7cc90e1 100644
--- a/doc/administration/geo/replication/version_specific_updates.md
+++ b/doc/administration/geo/replication/version_specific_updates.md
@@ -11,6 +11,41 @@ Review this page for update instructions for your version. These steps
 accompany the [general steps](updating_the_geo_sites.md#general-update-steps)
 for updating Geo nodes.
 
+## Updating to 14.1, 14.2, 14.3
+
+We found an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/336013) where the Container Registry replication wasn't fully working if you used multi-arch images. In case of a multi-arch image, only the primary architecture (for example `amd64`) would be replicated to the secondary node. This has been [fixed in GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67624) and was backported to 14.2 and 14.1, but manual steps are required to force a re-sync.
+
+You can check if you are affected by running:
+
+```shell
+docker manifest inspect <SECONDARY_IMAGE_LOCATION> | jq '.mediaType'
+```
+
+Where `<SECONDARY_IMAGE_LOCATION>` is a container image on your secondary node.
+If the output matches `application/vnd.docker.distribution.manifest.list.v2+json`
+(there can be a `mediaType` entry at several levels, we only care about the top level entry),
+then you don't need to do anything.
+
+Otherwise, on all your **secondary** nodes, in a [Rails console](../../operations/rails_console.md), run the following:
+
+ ```ruby
+ list_type = 'application/vnd.docker.distribution.manifest.list.v2+json'
+
+ Geo::ContainerRepositoryRegistry.synced.each do |gcr|
+   cr = gcr.container_repository
+   primary = Geo::ContainerRepositorySync.new(cr)
+   cr.tags.each do |tag|
+     primary_manifest = JSON.parse(primary.send(:client).repository_raw_manifest(cr.path, tag.name))
+     next unless primary_manifest['mediaType'].eql?(list_type)
+
+     cr.delete_tag_by_name(tag.name)
+   end
+   primary.execute
+ end
+ ```
+
+If you are running a version prior to 14.1 and are using Geo and multi-arch containers in your Container Registry, we recommend [upgrading](updating_the_geo_sites.md) to at least GitLab 14.1.
+
 ## Updating to GitLab 14.0/14.1
 
 We found an issue where [Primary sites can not be removed from the UI](https://gitlab.com/gitlab-org/gitlab/-/issues/338231).
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index eb118709f94..1134ef8ac77 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -321,7 +321,7 @@ The different supported drivers are:
 | Driver       | Description                          |
 |--------------|--------------------------------------|
 | `filesystem` | Uses a path on the local file system |
-| `Azure`      | Microsoft Azure Blob Storage         |
+| `azure`      | Microsoft Azure Blob Storage         |
 | `gcs`        | Google Cloud Storage                 |
 | `s3`         | Amazon Simple Storage Service. Be sure to configure your storage bucket with the correct [S3 Permission Scopes](https://docs.docker.com/registry/storage-drivers/s3/#s3-permission-scopes). |
 | `swift`      | OpenStack Swift Object Storage       |
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index ef8330f8696..cb8d5c80d76 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -486,7 +486,7 @@ Authority (CA) in the system certificate store.
 
 For Omnibus, this is fixed by [installing a custom CA in Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-### Zip serving and cache configuration
+### ZIP serving and cache configuration
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/392) in GitLab 13.7.
 
@@ -494,19 +494,19 @@ WARNING:
 These are advanced settings. The recommended default values are set inside GitLab Pages. You should
 change these settings only if absolutely necessary. Use extreme caution.
 
-GitLab Pages can serve content from zip archives through object storage (an
+GitLab Pages can serve content from ZIP archives through object storage (an
 [issue](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/485) exists for supporting disk storage
-as well). It uses an in-memory cache to increase the performance when serving content from a zip
+as well). It uses an in-memory cache to increase the performance when serving content from a ZIP
 archive. You can modify the cache behavior by changing the following configuration flags.
 
 | Setting | Description |
 | ------- | ----------- |
-| `zip_cache_expiration` | The cache expiration interval of zip archives. Must be greater than zero to avoid serving stale content. Default is 60s. |
+| `zip_cache_expiration` | The cache expiration interval of ZIP archives. Must be greater than zero to avoid serving stale content. Default is 60s. |
 | `zip_cache_cleanup` | The interval at which archives are cleaned from memory if they have already expired. Default is 30s. |
 | `zip_cache_refresh` | The time interval in which an archive is extended in memory if accessed before `zip_cache_expiration`. This works together with `zip_cache_expiration` to determine if an archive is extended in memory. See the [example below](#zip-cache-refresh-example) for important details. Default is 30s. |
-| `zip_open_timeout` | The maximum time allowed to open a zip archive. Increase this time for big archives or slow network connections, as doing so may affect the latency of serving Pages. Default is 30s. |
+| `zip_open_timeout` | The maximum time allowed to open a ZIP archive. Increase this time for big archives or slow network connections, as doing so may affect the latency of serving Pages. Default is 30s. |
 
-#### Zip cache refresh example
+#### ZIP cache refresh example
 
 Archives are refreshed in the cache (extending the time they are held in memory) if they're accessed
 before `zip_cache_expiration`, and the time left before expiring is less than or equal to
@@ -520,7 +520,7 @@ opened) it's refreshed. This extends the time the archive remains in memory from
 After an archive reaches `zip_cache_expiration`, it's marked as expired and removed on the next
 `zip_cache_cleanup` interval.
 
-![Zip cache configuration](img/zip_cache_configuration.png)
+![ZIP cache configuration](img/zip_cache_configuration.png)
 
 ## Activate verbose logging for daemon
 
@@ -1014,7 +1014,7 @@ If you use [object storage](#using-object-storage), you can disable local storag
 
 Starting from GitLab 13.12, this setting also disables the [legacy storage](#migrate-legacy-storage-to-zip-storage), so if you were using NFS to serve Pages, you can completely disconnect from it.
 
-## Migrate GitLab Pages to 14.0
+## Prepare GitLab Pages for 14.0
 
 In GitLab 14.0 a number of breaking changes were introduced which may require some user intervention.
 The steps below describe the best way to migrate without causing any downtime for your GitLab instance.
@@ -1372,7 +1372,7 @@ both servers.
 
 GitLab 14.0 introduces a number of changes to GitLab Pages which may require manual intervention.
 
-1. Firstly [follow the migration guide](#migrate-gitlab-pages-to-140).
+1. Firstly [follow the migration guide](#prepare-gitlab-pages-for-140).
 1. Try to upgrade to GitLab 14.3 or above. Some of the issues were fixed in GitLab 14.1, 14.2 and 14.3.
 1. If it doesn't work, see [GitLab Pages logs](#how-to-see-gitlab-pages-logs), and if you see any errors there then search them on this page.
 
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index c55efe78216..382089bf438 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -243,7 +243,7 @@ project.update!(repository_read_only: true)
 ### Transfer project from one namespace to another
 
 ```ruby
- p= Project.find_by_full_path('<project_path>')
+p = Project.find_by_full_path('<project_path>')
 
  # To set the owner of the project
  current_user= p.creator
@@ -416,7 +416,7 @@ p.create_wiki  ### creates the wiki project on the filesystem
 ### In case of issue boards not loading properly and it's getting time out. We need to call the Issue Rebalancing service to fix this
 
 ```ruby
-p=Project.find_by_full_path('PROJECT PATH')
+p = Project.find_by_full_path('PROJECT PATH')
 
 IssueRebalancingService.new(p.issues.take).execute
 ```
@@ -999,8 +999,8 @@ This content has been moved to the [Troubleshooting Sidekiq docs](sidekiq.md).
 ### Get information about LFS objects and associated project
 
 ```ruby
-o=LfsObject.find_by(oid: "<oid>")
-p=Project.find(LfsObjectsProject.find_by_lfs_object_id(o.id).project_id)
+o = LfsObject.find_by(oid: "<oid>")
+p = Project.find(LfsObjectsProject.find_by_lfs_object_id(o.id).project_id)
 ```
 
 You can then delete these records from the database with:
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index 994c194c6db..3df957bacf9 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -116,7 +116,7 @@ References:
 ERROR: deadlock detected
 ```
 
-Three applicable timeouts are identified in the issue [#1](https://gitlab.com/gitlab-org/gitlab/-/issues/30528); our recommended settings are as follows:
+Three applicable timeouts are identified in the issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528); our recommended settings are as follows:
 
 ```ini
 deadlock_timeout = 5s
@@ -124,7 +124,7 @@ statement_timeout = 15s
 idle_in_transaction_session_timeout = 60s
 ```
 
-Quoting from issue [#1](https://gitlab.com/gitlab-org/gitlab/-/issues/30528):
+Quoting from issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528):
 
 > "If a deadlock is hit, and we resolve it through aborting the transaction after a short period, then the retry mechanisms we already have will make the deadlocked piece of work try again, and it's unlikely we'll deadlock multiple times in a row."
 
@@ -146,7 +146,7 @@ PostgresSQL defaults:
 - `statement_timeout = 0` (never)
 - `idle_in_transaction_session_timeout = 0` (never)
 
-Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/-/issues/30528)
+Comments in issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528)
 indicate that these should both be set to at least a number of minutes for all
 Omnibus GitLab installations (so they don't hang indefinitely). However, 15s
 for statement_timeout is very short, and will only be effective if the
diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index 009fb13c895..29a03fe06ab 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -45,7 +45,7 @@ can't link to files outside it.
 
 To ensure maximum availability of the cache, do one or more of the following:
 
-- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
+- [Tag your runners](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) and use the tag on jobs
   that share the cache.
 - [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
 - [Use a `key`](../yaml/index.md#cachekey) that fits your workflow. For example,
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 99bdc255f0e..925dff8751c 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -130,7 +130,7 @@ There are some important differences in the way runners work in comparison to ag
 
 - Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/runners_scope.md).
   They self-select jobs from the scopes you've defined automatically.
-- You can also [use tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
+- You can also [use tags](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) for finer control, and
   associate runners with specific jobs. For example, you can use a tag for jobs that
   require dedicated, more powerful, or specific hardware.
 - GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
@@ -230,7 +230,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
 The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/index.md)
 to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
 of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users).
-We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
+We also support using [tags](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run) to direct different jobs
 to different runners (execution agents).
 
 The `agent` section also allows you to define which Docker images should be used for execution, for which we use
diff --git a/doc/ci/runners/configure_runners.md b/doc/ci/runners/configure_runners.md
index 85c212c9ee1..13897b934c5 100644
--- a/doc/ci/runners/configure_runners.md
+++ b/doc/ci/runners/configure_runners.md
@@ -169,13 +169,13 @@ project.
 
 ![specific runner IP address](img/specific_runner_ip_address.png)
 
-## Use tags to limit the number of jobs using the runner
+## Use tags to control which jobs a runner can run
 
 You must set up a runner to be able to run all the different types of jobs
 that it may encounter on the projects it's shared over. This would be
 problematic for large amounts of projects, if it weren't for tags.
 
-GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with runners.
+GitLab CI/CD tags are not the same as Git tags. GitLab CI/CD tags are associated with runners.
 Git tags are associated with commits.
 
 By tagging a runner for the types of jobs it can handle, you can make sure
@@ -184,6 +184,8 @@ shared runners will [only run the jobs they are equipped to run](../yaml/index.m
 For instance, at GitLab we have runners tagged with `rails` if they contain
 the appropriate dependencies to run Rails test suites.
 
+### Set a runner to run untagged jobs
+
 When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
 [tagged jobs](../yaml/index.md#tags).
 To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
@@ -238,6 +240,48 @@ Example 2:
 1. A job that has no tags defined is executed and run.
 1. A second job that has a `docker` tag defined is stuck.
 
+### Use tags to run jobs on different platforms
+
+You can use tags to run different jobs on different platforms. For
+example, if you have an OS X runner with tag `osx` and a Windows runner with tag
+`windows`, you can run a job on each platform:
+
+```yaml
+windows job:
+  stage:
+    - build
+  tags:
+    - windows
+  script:
+    - echo Hello, %USERNAME%!
+
+osx job:
+  stage:
+    - build
+  tags:
+    - osx
+  script:
+    - echo "Hello, $USER!"
+```
+
+### Use CI/CD variables in tags
+
+> Introduced in [GitLab 14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/35742).
+
+You can use [CI/CD variables](../variables/index.md) with `tags` for dynamic runner selection:
+
+```yaml
+variables:
+  KUBERNETES_RUNNER: kubernetes
+
+  job:
+    tags:
+      - docker
+      - $KUBERNETES_RUNNER
+    script:
+      - echo "Hello runner selector feature"
+```
+
 ## Configure runner behavior with variables
 
 You can use [CI/CD variables](../variables/index.md) to configure runner Git behavior
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index b6f5e3988c9..10713f3ae7c 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -1830,16 +1830,22 @@ rspec:
 > - A limit of 50 tags per job [enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/338929) in GitLab 14.3.
 > - A limit of 50 tags per job [enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/339855) in GitLab 14.3.
 
-In [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/338479) and later, the number of tags must be less than `50`.
-
 Use `tags` to select a specific runner from the list of all runners that are
 available for the project.
 
 When you register a runner, you can specify the runner's tags, for
-example `ruby`, `postgres`, `development`.
+example `ruby`, `postgres`, or `development`. To pick up and run a job, a runner must
+be assigned every tag listed in the job.
+
+**Keyword type**: Job keyword. You can use it only as part of a job or in the
+[`default:` section](#custom-default-keyword-values).
+
+**Possible inputs**:
+
+- An array of tag names.
+- [CI/CD variables](../runners/configure_runners.md#use-cicd-variables-in-tags) in GitLab 14.1 and later.
 
-In the following example, the job is run by a runner that
-has both `ruby` and `postgres` tags defined.
+**Example of `tags`**:
 
 ```yaml
 job:
@@ -1848,42 +1854,16 @@ job:
     - postgres
 ```
 
-You can use tags to run different jobs on different platforms. For
-example, if you have an OS X runner with tag `osx` and a Windows runner with tag
-`windows`, you can run a job on each platform:
+In this example, only runners with *both* the `ruby` and `postgres` tags can run the job.
 
-```yaml
-windows job:
-  stage:
-    - build
-  tags:
-    - windows
-  script:
-    - echo Hello, %USERNAME%!
-
-osx job:
-  stage:
-    - build
-  tags:
-    - osx
-  script:
-    - echo "Hello, $USER!"
-```
+**Additional details**:
 
-In [GitLab 14.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/35742), you can
-use [CI/CD variables](../variables/index.md) with `tags` for dynamic runner selection:
+- In [GitLab 14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/338479) and later,
+  the number of tags must be less than `50`.
 
-```yaml
-variables:
-  KUBERNETES_RUNNER: kubernetes
+**Related topics**:
 
-  job:
-    tags:
-      - docker
-      - $KUBERNETES_RUNNER
-    script:
-      - echo "Hello runner selector feature"
-```
+- [Use tags to control which jobs a runner can run](../runners/configure_runners.md#use-tags-to-control-which-jobs-a-runner-can-run).
 
 ### `allow_failure`
 
@@ -3403,7 +3383,22 @@ You can specify the number of [retry attempts for certain stages of job executio
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/14887) in GitLab 12.3.
 
-Use `timeout` to configure a timeout for a specific job. For example:
+Use `timeout` to configure a timeout for a specific job. If the job runs for longer
+than the timeout, the job fails.
+
+The job-level timeout can be longer than the [project-level timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run).
+but can't be longer than the [runner's timeout](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
+
+**Keyword type**: Job keyword. You can use it only as part of a job or in the
+[`default:` section](#custom-default-keyword-values).
+
+**Possible inputs**: A period of time written in natural language. For example, these are all equivalent:
+
+- `3600 seconds`
+- `60 minutes`
+- `one hour`
+
+**Example of `timeout`**:
 
 ```yaml
 build:
@@ -3415,10 +3410,6 @@ test:
   timeout: 3h 30m
 ```
 
-The job-level timeout can exceed the
-[project-level timeout](../pipelines/settings.md#set-a-limit-for-how-long-jobs-can-run) but can't
-exceed the runner-specific timeout.
-
 ### `parallel`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21480) in GitLab 11.5.
diff --git a/lib/gitlab/database/load_balancing/host.rb b/lib/gitlab/database/load_balancing/host.rb
index 670a373ded1..acd7df0a263 100644
--- a/lib/gitlab/database/load_balancing/host.rb
+++ b/lib/gitlab/database/load_balancing/host.rb
@@ -163,8 +163,6 @@ module Gitlab
 
         def primary_write_location
           load_balancer.primary_write_location
-        ensure
-          load_balancer.release_primary_connection
         end
 
         def database_replica_location
diff --git a/lib/gitlab/database/load_balancing/primary_host.rb b/lib/gitlab/database/load_balancing/primary_host.rb
index 795fa7c3909..e379652c260 100644
--- a/lib/gitlab/database/load_balancing/primary_host.rb
+++ b/lib/gitlab/database/load_balancing/primary_host.rb
@@ -16,7 +16,8 @@ module Gitlab
         end
 
         def release_connection
-          @load_balancer.release_primary_connection
+          # no-op as releasing primary connections isn't needed.
+          nil
         end
 
         def enable_query_cache!
@@ -51,8 +52,6 @@ module Gitlab
 
         def primary_write_location
           @load_balancer.primary_write_location
-        ensure
-          @load_balancer.release_primary_connection
         end
 
         def database_replica_location
diff --git a/spec/features/issues/issue_detail_spec.rb b/spec/features/issues/issue_detail_spec.rb
index a942a1a44f6..531c3634b5e 100644
--- a/spec/features/issues/issue_detail_spec.rb
+++ b/spec/features/issues/issue_detail_spec.rb
@@ -32,6 +32,21 @@ RSpec.describe 'Issue Detail', :js do
     end
   end
 
+  context 'when issue description has emojis' do
+    let(:issue) { create(:issue, project: project, author: user, description: 'hello world :100:') }
+
+    before do
+      sign_in(user)
+      visit project_issue_path(project, issue)
+    end
+
+    it 'renders gl-emoji tag' do
+      page.within('.description') do
+        expect(page).to have_selector('gl-emoji', count: 1)
+      end
+    end
+  end
+
   context 'when issue description has xss snippet' do
     before do
       issue.update!(description: '![xss" onload=alert(1);//](a)')
diff --git a/spec/frontend/lib/dompurify_spec.js b/spec/frontend/lib/dompurify_spec.js
index 696e2ba6e13..324441fa2c9 100644
--- a/spec/frontend/lib/dompurify_spec.js
+++ b/spec/frontend/lib/dompurify_spec.js
@@ -65,6 +65,10 @@ describe('~/lib/dompurify', () => {
     expect(sanitize(htmlXlink)).toBe(htmlXlink);
   });
 
+  it("doesn't sanitize gl-emoji", () => {
+    expect(sanitize('<p><gl-emoji>💯</gl-emoji></p>')).toBe('<p><gl-emoji>💯</gl-emoji></p>');
+  });
+
   describe.each`
     type          | gon
     ${'root'}     | ${rootGon}
diff --git a/spec/lib/gitlab/database/load_balancing/primary_host_spec.rb b/spec/lib/gitlab/database/load_balancing/primary_host_spec.rb
index 92c07a489bb..a0e63a7ee4e 100644
--- a/spec/lib/gitlab/database/load_balancing/primary_host_spec.rb
+++ b/spec/lib/gitlab/database/load_balancing/primary_host_spec.rb
@@ -20,10 +20,8 @@ RSpec.describe Gitlab::Database::LoadBalancing::PrimaryHost do
   end
 
   describe '#release_connection' do
-    it 'releases a connection from the pool' do
-      expect(load_balancer).to receive(:release_primary_connection)
-
-      host.release_connection
+    it 'does nothing' do
+      expect(host.release_connection).to be_nil
     end
   end