Add latest changes from gitlab-org/gitlab@master

17 files changed, 271 insertions, 57 deletions

diff --git a/GITALY_SERVER_VERSION b/GITALY_SERVER_VERSION
index e70273b30d6..68408a5f640 100644
--- a/GITALY_SERVER_VERSION
+++ b/GITALY_SERVER_VERSION
@@ -1 +1 @@
-2e3b774032b4759603cc3f668d648eecf8066953
+bda5c66c7a4207b1bfae779f367eba0776873cd5
diff --git a/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml b/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml
index bfef9b0ed10..a1e70246309 100755
--- a/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml
+++ b/config/metrics/counts_28d/20210216184559_ci_templates_total_unique_counts_monthly.yml
@@ -30,6 +30,7 @@ options:
   - p_ci_templates_rust
   - p_ci_templates_elixir
   - p_ci_templates_clojure
+  - p_ci_templates_cosign
   - p_ci_templates_crystal
   - p_ci_templates_getting_started
   - p_ci_templates_code_quality
diff --git a/config/metrics/counts_28d/20230830153031_p_ci_templates_cosign_monthly.yml b/config/metrics/counts_28d/20230830153031_p_ci_templates_cosign_monthly.yml
new file mode 100644
index 00000000000..95071956e38
--- /dev/null
+++ b/config/metrics/counts_28d/20230830153031_p_ci_templates_cosign_monthly.yml
@@ -0,0 +1,25 @@
+---
+key_path: redis_hll_counters.ci_templates.p_ci_templates_cosign_monthly
+description: Count of pipelines using the Cosign CI template.
+product_section: ci
+product_stage: verify
+product_group: pipeline_security
+value_type: number
+status: active
+milestone: "16.4"
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130339
+time_frame: 28d
+data_source: redis_hll
+data_category: optional
+instrumentation_class: RedisHLLMetric
+performance_indicator_type: []
+distribution:
+- ce
+- ee
+tier:
+- free
+- premium
+- ultimate
+options:
+  events:
+    - p_ci_templates_cosign
diff --git a/config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml b/config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml
index 3e1becde7d7..3c410b59322 100755
--- a/config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml
+++ b/config/metrics/counts_7d/20210216184557_ci_templates_total_unique_counts_weekly.yml
@@ -30,6 +30,7 @@ options:
   - p_ci_templates_rust
   - p_ci_templates_elixir
   - p_ci_templates_clojure
+  - p_ci_templates_cosign
   - p_ci_templates_crystal
   - p_ci_templates_getting_started
   - p_ci_templates_code_quality
diff --git a/config/metrics/counts_7d/20230830153031_p_ci_templates_cosign_weekly.yml b/config/metrics/counts_7d/20230830153031_p_ci_templates_cosign_weekly.yml
new file mode 100644
index 00000000000..2de155a0406
--- /dev/null
+++ b/config/metrics/counts_7d/20230830153031_p_ci_templates_cosign_weekly.yml
@@ -0,0 +1,25 @@
+---
+key_path: redis_hll_counters.ci_templates.p_ci_templates_cosign_weekly
+description: Count of pipelines using the Cosign CI template.
+product_section: ci
+product_stage: verify
+product_group: pipeline_security
+value_type: number
+status: active
+milestone: "16.4"
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130339
+time_frame: 7d
+data_source: redis_hll
+data_category: optional
+instrumentation_class: RedisHLLMetric
+performance_indicator_type: []
+distribution:
+- ce
+- ee
+tier:
+- free
+- premium
+- ultimate
+options:
+  events:
+    - p_ci_templates_cosign
diff --git a/doc/ci/runners/new_creation_workflow.md b/doc/ci/runners/new_creation_workflow.md
index 3e4a128b493..9a3886430de 100644
--- a/doc/ci/runners/new_creation_workflow.md
+++ b/doc/ci/runners/new_creation_workflow.md
@@ -15,7 +15,7 @@ The development, release, and timing of any products, features, or functionality
 sole discretion of GitLab Inc.
 
 In GitLab 16.0, we introduced a new runner creation workflow that uses runner authentication tokens to register
-runners. The legacy workflow that uses registration tokens is deprecated and will be removed in GitLab 17.0.
+runners. The legacy workflow that uses registration tokens is deprecated and will be removed in GitLab 18.0.
 
 For information about the current development status of the new workflow, see [epic 7663](https://gitlab.com/groups/gitlab-org/-/epics/7663).
 
diff --git a/doc/development/database/clickhouse/clickhouse_within_gitlab.md b/doc/development/database/clickhouse/clickhouse_within_gitlab.md
index 597b1732abb..297776429d7 100644
--- a/doc/development/database/clickhouse/clickhouse_within_gitlab.md
+++ b/doc/development/database/clickhouse/clickhouse_within_gitlab.md
@@ -149,6 +149,45 @@ query = builder
 rows = ClickHouse::Client.select(query, :main)
 ```
 
+## Inserting data
+
+The ClickHouse client supports inserting data through the standard query interface:
+
+```ruby
+raw_query = 'INSERT INTO events (id, target_type) VALUES ({id:UInt64}, {target_type:String})'
+placeholders = { id: 1, target_type: 'Issue' }
+
+query = ClickHouse::Client::Query.new(raw_query: raw_query, placeholders: placeholders)
+rows = ClickHouse::Client.execute(query, :main)
+```
+
+Inserting data this way is acceptable if:
+
+- The table contains settings or configuration data where we need to add one row.
+- For testing, test data has to be prepared in the database.
+
+When inserting data, we should always try to use batch processing where multiple rows are inserted at once. Building large `INSERT` queries in memory is discouraged because of the increased memory usage. Additionally, values specified within such queries cannot be redacted automatically by the client.
+
+To compress data and reduce memory usage, insert CSV data. You can do this with the internal [`CsvBuilder`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/csv_builder) gem:
+
+```ruby
+iterator = Event.find_each
+
+# insert from events table using only the id and the target_type columns
+column_mapping = {
+  id: :id,
+  target_type: :target_type
+}
+
+CsvBuilder::Gzip.new(iterator, column_mapping).render do |tempfile|
+  query = 'INSERT INTO events (id, target_type) FORMAT CSV'
+  ClickHouse::Client.insert_csv(query, File.open(tempfile.path), :main)
+end
+```
+
+NOTE:
+It's important to test and verify efficient batching of database records from PostgreSQL. Consider using the techniques described in the [Iterating tables in batches](../iterating_tables_in_batches.md).
+
 ## Testing
 
 ClickHouse is enabled on CI/CD but to avoid significantly affecting the pipeline runtime we've decided to run the ClickHouse server for test cases tagged with `:click_house` only.
diff --git a/doc/development/fe_guide/customizable_dashboards.md b/doc/development/fe_guide/customizable_dashboards.md
index ac8b0b8a1ab..91983b12818 100644
--- a/doc/development/fe_guide/customizable_dashboards.md
+++ b/doc/development/fe_guide/customizable_dashboards.md
@@ -123,6 +123,7 @@ import { pageViewsOverTime } from './visualizations';
 export const dashboard = {
   slug: 'my_dashboard', // Used to set the URL path for the dashboard.
   title: 'My dashboard title', // The title to display.
+  description: 'This is a description of the dashboard', // A description of the dashboard
   // Each dashboard consists of an array of panels to display.
   panels: [
     {
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index 416a8f2a213..0bfd66437a5 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -80,6 +80,9 @@ Every user is included in seat usage, with the following exceptions:
 
 - Users who are pending approval.
 - Members with the [Guest role on an Ultimate subscription](#free-guest-users).
+- Members with the [minimal access role](../../user/permissions.md#users-with-minimal-access).
+- [Banned members](../../user/group/moderate_users.md#ban-a-user).
+- [Blocked users](../../administration/moderate_users.md#block-a-user).
 - GitLab-created service accounts:
   - [Ghost User](../../user/profile/account/delete_account.md#associated-records).
   - Bots such as:
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md
index 03653e6a0e2..3ec1151b1d6 100644
--- a/doc/user/application_security/vulnerability_report/index.md
+++ b/doc/user/application_security/vulnerability_report/index.md
@@ -40,8 +40,6 @@ status of a Jira issue is not shown in the GitLab UI.
 
 ## Project-level Vulnerability Report
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6165) in GitLab 11.1.
-
 At the project level, the Vulnerability Report also contains:
 
 - A time stamp showing when it was updated, including a link to the latest pipeline.
@@ -129,8 +127,6 @@ The content of the Project filter depends on the current level:
 
 ### Activity filter
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259255) in GitLab 13.9
-
 The Activity filter behaves differently from the other filters. The selected values form mutually
 exclusive sets to allow for precisely locating the desired vulnerability records. Additionally, not
 all options can be selected in combination.
@@ -150,8 +146,6 @@ To view more details of a vulnerability, select the vulnerability's **Descriptio
 
 ## View vulnerable source location
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267509) in GitLab 13.10.
-
 Some security scanners output the filename and line number of a potential vulnerability. When
 that information is available, the vulnerability's details include a link to the relevant file,
 in the default branch.
@@ -160,8 +154,7 @@ To view the relevant file, select the filename in the vulnerability's details.
 
 ## Change status of vulnerabilities
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292636) in GitLab 13.10, all statuses became selectable.
-> - Providing a comment and dismissal reason [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/408366) in GitLab 16.0.
+> Providing a comment and dismissal reason [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/408366) in GitLab 16.0.
 
 From the Vulnerability Report you can change the status of one or more vulnerabilities.
 
@@ -184,9 +177,6 @@ To sort vulnerabilities by the date each vulnerability was detected, select the
 
 ## Export vulnerability details
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213014) in the Security Center (previously known as the Instance Security Dashboard) and project-level Vulnerability Report (previously known as the Project Security Dashboard) in GitLab 13.0.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213013) to the group-level Vulnerability Report in GitLab 13.1.
-
 You can export details of the vulnerabilities listed in the Vulnerability Report. The export format
 is CSV (comma separated values). All vulnerabilities are included because filters do not
 apply to the export.
@@ -229,8 +219,6 @@ thousands of vulnerabilities. Do not close the page until the download finishes.
 
 ## Dismiss a vulnerability
 
-> The option of adding a dismissal reason was introduced in GitLab 12.0.
-
 When you evaluate a vulnerability and decide it requires no more action,
 you can mark it as **Dismissed**.
 Dismissed vulnerabilities do not appear in the merge request security widget
diff --git a/doc/user/project/codeowners/index.md b/doc/user/project/codeowners/index.md
index f871bee93f7..8a450fdb64f 100644
--- a/doc/user/project/codeowners/index.md
+++ b/doc/user/project/codeowners/index.md
@@ -6,17 +6,16 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Code Owners **(PREMIUM ALL)**
 
-> Moved to GitLab Premium in 13.9.
-
 Use the Code Owners feature to define who has expertise for specific parts of your project's codebase.
 Define the owners of files and directories in a repository to:
 
 - **Require owners to approve changes.** Combine protected branches with Code Owners to require
   experts to approve merge requests before they merge into a protected branch.
 - **Identify owners.** Code Owner names are displayed on the files and directories they own:
+
   ![Code Owners displayed in UI](../img/codeowners_in_UI_v15_10.png)
 
-Use Code Owners in combination with merge request
+Combine Code Owners with merge request
 [approval rules](../merge_requests/approvals/rules.md) (either optional or required)
 to build a flexible approval workflow:
 
@@ -42,8 +41,6 @@ For example:
   <iframe src="https://www.youtube-nocookie.com/embed/RoyBySTUSB0" frameborder="0" allowfullscreen> </iframe>
 </figure>
 
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-
 ## View Code Owners of a file or directory
 
 To view the Code Owners of a file or directory:
@@ -57,14 +54,14 @@ GitLab shows the Code Owners at the top of the page.
 
 ## Set up Code Owners
 
-1. Create a `CODEOWNERS` file in your [preferred location](#code-owners-file).
+1. Create a `CODEOWNERS` file in your [preferred location](#codeowners-file).
 1. Define some rules in the file following the [Code Owners syntax reference](reference.md).
    Some suggestions:
    - Configure [All eligible approvers](../merge_requests/approvals/rules.md#code-owners-as-eligible-approvers) approval rule.
    - [Require Code Owner approval](../protected_branches.md#require-code-owner-approval-on-a-protected-branch) on a protected branch.
 1. Commit your changes, and push them up to GitLab.
 
-### Code Owners file
+### `CODEOWNERS` file
 
 A `CODEOWNERS` file (with no extension) specifies the users or
 [shared groups](../members/share_project_with_groups.md) responsible for
@@ -78,9 +75,9 @@ all others are ignored:
 1. In the `docs` directory: `./docs/CODEOWNERS`.
 1. In the `.gitlab` directory: `./.gitlab/CODEOWNERS`.
 
-### Add a group as a Code Owner
+For more information, see [Code Owners syntax and error handling](reference.md).
 
-> Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in GitLab 13.0.
+### Add a group as a Code Owner
 
 To set the members of a group or subgroup as a Code Owner:
 
@@ -99,8 +96,6 @@ file.md @group-x @group-x/subgroup-y
 
 #### Group inheritance and eligibility
 
-> Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in GitLab 13.0.
-
 ```mermaid
 graph TD
     A[Parent group X] -->|owns| B[Project A]
@@ -188,9 +183,6 @@ Only one CODEOWNERS pattern per section is matched to a file path.
 
 ### Organize Code Owners by putting them into sections
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12137) in GitLab 13.2 [with a flag](../../../administration/feature_flags.md) named `sectional_codeowners`. Disabled by default.
-> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42389) in GitLab 13.4. Feature flag `sectional_codeowners` removed.
-
 You can organize Code Owners by putting them into named sections.
 
 You can use sections for shared directories, so that multiple
@@ -215,9 +207,10 @@ The following image shows a **Groups** and **Documentation** section:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/371711) in GitLab 15.11 [with a flag](../../../administration/feature_flags.md) named `codeowners_default_owners`. Disabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115888) in GitLab 15.11. Feature flag `codeowners_default_owners` removed.
 
-If multiple file paths inside a section share the same ownership, define a default
-Code Owner for the section. All paths in that section inherit this default, unless
-you override the section default on a specific line.
+If multiple file paths inside a section share the same ownership, define default
+Code Owners for the section.
+All paths in that section inherit this default, unless you override the section
+default on a specific line.
 
 Default owners are applied when specific owners are not specified for file paths.
 Specific owners defined beside the file path override default owners:
@@ -227,7 +220,7 @@ Specific owners defined beside the file path override default owners:
 docs/
 README.md
 
-[Database] @database-team
+[Database] @database-team @agarcia
 model/db/
 config/db/database-setup.md @docs-team
 ```
@@ -235,9 +228,14 @@ config/db/database-setup.md @docs-team
 In this example:
 
 - `@docs-team` owns all items in the `Documentation` section.
-- `@database-team` owns all items in the `Database` section except
+- `@database-team` and `@agarcia` own all items in the `Database` section except
   `config/db/database-setup.md`, which has an override assigning it to `@docs-team`.
 
+Compare this behavior by using [regular entries and sections together](#use-regular-entries-and-sections-together),
+when entries in sections don't override entries without sections.
+
+#### Use default owners and optional sections together
+
 To combine the syntax for default owners with [optional sections](#make-a-code-owners-section-optional)
 and required approvals, place default owners at the end:
 
@@ -251,6 +249,38 @@ model/db/
 config/db/database-setup.md @docs-team
 ```
 
+#### Use regular entries and sections together
+
+If you set a default Code Owner for a path outside a section, their approval is always required, and
+the entry isn't overridden.
+Entries without sections are treated as if they were another, unnamed section:
+
+```plaintext
+# Required for all files
+* @general-approvers
+
+[Documentation] @docs-team
+docs/
+README.md
+*.txt
+
+[Database] @database-team
+model/db/
+config/db/database-setup.md @docs-team
+```
+
+In this example:
+
+- `@general-approvers` owns all items everywhere, without overrides.
+- `@docs-team` owns all items in the `Documentation` section.
+- `@database-team` owns all items in the `Database` section except
+  `config/db/database-setup.md`, which has an override assigning it to `@docs-team`.
+- A merge request that modifies `model/db/CHANGELOG.txt` would require three approvals: one from each
+  of the `@general-approvers`,`@docs-team`, and `@database-team` groups.
+
+Compare this behavior by using only [default owners for sections](#set-default-owner-for-a-section),
+when specific entries within a section override the section default.
+
 #### Sections with duplicate names
 
 If multiple sections have the same name, they are combined.
@@ -275,8 +305,6 @@ entries under **Database**. The entries defined under the sections **Documentati
 
 #### Make a Code Owners section optional
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232995) in GitLab 13.8.
-
 You can designate optional sections in your Code Owners file. Prepend the
 section name with the caret `^` character to treat the entire section as optional.
 Optional sections enable you to designate responsible parties for various parts
@@ -314,14 +342,14 @@ section is marked as optional.
 
 You can require multiple approvals for the Code Owners sections under the Approval Rules area in merge requests.
 Append the section name with a number `n` in brackets. This requires `n` approvals from the Code Owners in this section.
-Please note valid entries for `n` are integers `≥ 1`. `[1]` is optional as it is the default. Invalid values for `n` are treated as `1`.
+Valid entries for `n` are integers `≥ 1`. `[1]` is optional because it is the default. Invalid values for `n` are treated as `1`.
 
 WARNING:
 [Issue #384881](https://gitlab.com/gitlab-org/gitlab/-/issues/385881) proposes changes
 to the behavior of this setting. Do not intentionally set invalid values. They may
 become valid in the future, and cause unexpected behavior.
 
-Please confirm you enabled `Require approval from code owners` in `Settings > Repository > Protected branches`, otherwise the Code Owner approvals will be optional.
+Make sure you enabled `Require approval from code owners` in `Settings > Repository > Protected branches`, otherwise the Code Owner approvals are optional.
 
 In this example, the `[Documentation]` section requires 2 approvals:
 
@@ -337,7 +365,7 @@ The `Documentation` Code Owners section under the **Approval Rules** area displa
 
 ![MR widget - Multiple Approval Code Owners sections](../img/multi_approvals_code_owners_sections_v15_9.png)
 
-### Allowed to Push
+### Allowed to push
 
 Users who are **Allowed to push** can choose to create a merge request
 for their changes, or push the changes directly to a branch. If the user
@@ -350,12 +378,15 @@ and release tooling.
 
 All changes from users _without_ the **Allowed to push** permission must be routed through a merge request.
 
-## Technical Resources
+## Related topics
 
-[Code Owners development guidelines](../../../development/code_owners/index.md)
+- [Syntax reference](reference.md)
+- [Development guidelines](../../../development/code_owners/index.md)
 
 ## Troubleshooting
 
+When working with Code Owners, you might encounter the following issues.
+
 For more information about how the Code Owners feature handles errors, see the
 [Code Owners reference](reference.md).
 
@@ -363,7 +394,8 @@ For more information about how the Code Owners feature handles errors, see the
 
 A Code Owner approval rule is optional if any of these conditions are true:
 
-- The user or group are not a member of the project. Code Owners [cannot inherit from parent groups](https://gitlab.com/gitlab-org/gitlab/-/issues/288851/).
+- The user or group is not a member of the project.
+  Code Owners [cannot inherit members from parent groups](https://gitlab.com/gitlab-org/gitlab/-/issues/288851/).
 - [Code Owner approval on a protected branch](../protected_branches.md#require-code-owner-approval-on-a-protected-branch) has not been set up.
 - The section is [marked as optional](#make-a-code-owners-section-optional).
 
@@ -383,7 +415,15 @@ if any of these conditions are true:
   member of the Code Owner group.
 - Current user is an external user who does not have permission to the internal Code Owner group.
 
-### Approval rule is invalid. GitLab has approved this rule automatically to unblock the merge request
+### Approval rule is invalid
+
+You might get an error that states:
+
+```plaintext
+Approval rule is invalid.
+GitLab has approved this rule automatically to unblock the merge request.
+```
+
+This issue occurs when an approval rule uses a Code Owner that is not a direct member of the project.
 
-This message may appear if an approval rule uses a Code Owner that is not a direct member of the project.
-Check that the group or user has been invited to the project.
+The workaround is to check that the group or user has been invited to the project.
diff --git a/gems/click_house-client/lib/click_house/client/formatter.rb b/gems/click_house-client/lib/click_house/client/formatter.rb
index bb60d8db7f7..de7ae72bdf8 100644
--- a/gems/click_house-client/lib/click_house/client/formatter.rb
+++ b/gems/click_house-client/lib/click_house/client/formatter.rb
@@ -7,7 +7,8 @@ module ClickHouse
 
       TYPE_CASTERS = {
         'UInt64' => ->(value) { Integer(value) },
-        "DateTime64(6, 'UTC')" => ->(value) { ActiveSupport::TimeZone["UTC"].parse(value) }
+        "DateTime64(6, 'UTC')" => ->(value) { ActiveSupport::TimeZone['UTC'].parse(value) },
+        "IntervalSecond" => ->(value) { ActiveSupport::Duration.build(value.to_i) }
       }.freeze
 
       def self.format(result)
diff --git a/gems/click_house-client/spec/click_house/client/formatter_spec.rb b/gems/click_house-client/spec/click_house/client/formatter_spec.rb
new file mode 100644
index 00000000000..0af3aa0bdbc
--- /dev/null
+++ b/gems/click_house-client/spec/click_house/client/formatter_spec.rb
@@ -0,0 +1,63 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe ClickHouse::Client::Formatter do
+  it 'formats values according to types in metadata' do
+    # this query here is just for documentation purposes, it generates the response below
+    _query = <<~SQL.squish
+      SELECT toUInt64(1) as uint64,
+             toDateTime64('2016-06-15 23:00:00', 6, 'UTC') as datetime64_6,
+             INTERVAL 1 second as interval_second
+    SQL
+
+    response_json = <<~JSON
+{
+	"meta":
+	[
+		{
+			"name": "uint64",
+			"type": "UInt64"
+		},
+		{
+			"name": "datetime64_6",
+			"type": "DateTime64(6, 'UTC')"
+		},
+		{
+			"name": "interval_second",
+			"type": "IntervalSecond"
+		}
+	],
+
+	"data":
+	[
+		{
+			"uint64": "1",
+			"datetime64_6": "2016-06-15 23:00:00.000000",
+			"interval_second": "1"
+		}
+	],
+
+	"rows": 1,
+
+	"statistics":
+	{
+		"elapsed": 0.002101,
+		"rows_read": 1,
+		"bytes_read": 1
+	}
+}
+    JSON
+
+    parsed_response = JSON.parse(response_json)
+    formatted_response = described_class.format(parsed_response)
+
+    expect(formatted_response).to(
+      eq(
+        [{ "uint64" => 1,
+           "datetime64_6" => ActiveSupport::TimeZone["UTC"].parse("2016-06-15 23:00:00"),
+           "interval_second" => 1.second }]
+      )
+    )
+  end
+end
diff --git a/gems/config/rubocop.yml b/gems/config/rubocop.yml
index 58746de53b0..72b37aa60b5 100644
--- a/gems/config/rubocop.yml
+++ b/gems/config/rubocop.yml
@@ -2,7 +2,7 @@
 # (AllCops/Exclude: 'gems/**/*') if RuboCop cop is run within `gems/...`.
 # See https://gitlab.com/gitlab-org/gitlab/-/issues/417281
 <%
-  relative_path = ENV['PWD'].delete_prefix(File.expand_path('../..')) 
+  relative_path = ENV['PWD'].delete_prefix(File.expand_path('../..'))
   RuboCop::ConfigLoader.ignore_parent_exclusion = relative_path.start_with?('/gems/')
 %>
 ---
@@ -61,6 +61,9 @@ Gitlab/RSpec/AvoidSetup:
 Graphql/AuthorizeTypes:
   Enabled: false
 
+Gitlab/Json:
+  Enabled: false
+
 # This cop doesn't make sense in the context of gems
 Graphql/Descriptions:
   Enabled: false
diff --git a/lib/gitlab/ci/templates/Cosign.gitlab-ci.yml b/lib/gitlab/ci/templates/Cosign.gitlab-ci.yml
new file mode 100644
index 00000000000..48c9422b469
--- /dev/null
+++ b/lib/gitlab/ci/templates/Cosign.gitlab-ci.yml
@@ -0,0 +1,22 @@
+# To contribute improvements to CI/CD templates, please follow the Development guide at:
+# https://docs.gitlab.com/ee/development/cicd/templates.html
+# This specific template is located at:
+# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Cosign.gitlab-ci.yml
+
+# This template extends Docker.gitlab-ci.yml to sign the image with Cosign after building.
+# This allows you to verify that an image was built by a trusted pipeline before running it.
+# See https://docs.gitlab.com/ee/ci/yaml/signing_examples.html for more details.
+
+include:
+  template: Docker.gitlab-ci.yml
+
+docker-build:
+  variables:
+    COSIGN_YES: "true" # Used by Cosign to skip confirmation prompts for non-destructive operations
+  id_tokens:
+    SIGSTORE_ID_TOKEN: # Used by Cosign to get certificate from Fulcio
+      aud: sigstore
+  after_script:
+    - apk add --update cosign
+    - IMAGE_DIGEST="$(docker inspect --format='{{index .RepoDigests 0}}' "$DOCKER_IMAGE_NAME")"
+    - cosign sign "$IMAGE_DIGEST"
diff --git a/lib/gitlab/ci/templates/Docker.gitlab-ci.yml b/lib/gitlab/ci/templates/Docker.gitlab-ci.yml
index 8f5f0e2c451..1aa346aec67 100644
--- a/lib/gitlab/ci/templates/Docker.gitlab-ci.yml
+++ b/lib/gitlab/ci/templates/Docker.gitlab-ci.yml
@@ -15,21 +15,20 @@ docker-build:
   stage: build
   services:
     - docker:dind
+  variables:
+    DOCKER_IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG
   before_script:
     - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
-  # Default branch leaves tag empty (= latest tag)
-  # All other branches are tagged with the escaped branch name (commit ref slug)
+  # All branches are tagged with $DOCKER_IMAGE_NAME (defaults to commit ref slug)
+  # Default branch is also tagged with `latest`
   script:
+    - docker build --pull -t "$DOCKER_IMAGE_NAME" .
+    - docker push "$DOCKER_IMAGE_NAME"
     - |
       if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
-        tag=""
-        echo "Running on default branch '$CI_DEFAULT_BRANCH': tag = 'latest'"
-      else
-        tag=":$CI_COMMIT_REF_SLUG"
-        echo "Running on branch '$CI_COMMIT_BRANCH': tag = $tag"
+        docker tag "$DOCKER_IMAGE_NAME" "$CI_REGISTRY_IMAGE:latest"
+        docker push "$CI_REGISTRY_IMAGE:latest"
       fi
-    - docker build --pull -t "$CI_REGISTRY_IMAGE${tag}" .
-    - docker push "$CI_REGISTRY_IMAGE${tag}"
   # Run this job in a branch where a Dockerfile exists
   rules:
     - if: $CI_COMMIT_BRANCH
diff --git a/qa/qa/runtime/browser.rb b/qa/qa/runtime/browser.rb
index 7bc4530287c..ce970d02e0a 100644
--- a/qa/qa/runtime/browser.rb
+++ b/qa/qa/runtime/browser.rb
@@ -151,6 +151,7 @@ module QA
               driver: 'ALL',
               server: 'ALL'
             }
+
           when :safari
             if QA::Runtime::Env.remote_mobile_device_name
               webdriver_options.platform_name = 'iOS'
@@ -159,9 +160,11 @@ module QA
               webdriver_options.add_option('appium:platformVersion', 'latest')
             end
           when :firefox
-            webdriver_options.add_option('acceptInsecureCerts', true) if QA::Runtime::Env.accept_insecure_certs?
+            webdriver_options.accept_insecure_certs = true if QA::Runtime::Env.accept_insecure_certs?
+            webdriver_options.args << "--headless" if QA::Runtime::Env.webdriver_headless?
           when :edge
             webdriver_options.args << "--window-size=#{DEFAULT_WINDOW_SIZE}"
+            webdriver_options.args << "headless" if QA::Runtime::Env.webdriver_headless?
           end
 
           selenium_options = {