Automatic merge of gitlab-org/gitlab master

app/controllers/jira_connect/events_controller.rb

@@ -19,7 +19,7 @@ class JiraConnect::EventsController < JiraConnect::ApplicationController
   end
 
   def uninstalled
-    if current_jira_installation.destroy
+    if JiraConnectInstallations::DestroyService.execute(current_jira_installation, jira_connect_base_path, jira_connect_events_uninstalled_path)
       head :ok
     else
       head :unprocessable_entity

app/services/jira_connect_installations/destroy_service.rb

+# frozen_string_literal: true
+
+module JiraConnectInstallations
+  class DestroyService
+    def self.execute(installation, jira_connect_base_path, jira_connect_uninstalled_event_path)
+      new(installation, jira_connect_base_path, jira_connect_uninstalled_event_path).execute
+    end
+
+    def initialize(installation, jira_connect_base_path, jira_connect_uninstalled_event_path)
+      @installation = installation
+      @jira_connect_base_path = jira_connect_base_path
+      @jira_connect_uninstalled_event_path = jira_connect_uninstalled_event_path
+    end
+
+    def execute
+      if @installation.instance_url.present?
+        JiraConnect::ForwardEventWorker.perform_async(@installation.id, @jira_connect_base_path, @jira_connect_uninstalled_event_path)
+        return true
+      end
+
+      @installation.destroy
+    end
+  end
+end

app/workers/all_queues.yml

@@ -1078,6 +1078,15 @@
   :weight: 2
   :idempotent: true
   :tags: []
+- :name: jira_connect:jira_connect_forward_event
+  :worker_name: JiraConnect::ForwardEventWorker
+  :feature_category: :integrations
+  :has_external_dependencies: true
+  :urgency: :low
+  :resource_boundary: :unknown
+  :weight: 1
+  :idempotent:
+  :tags: []
 - :name: jira_connect:jira_connect_sync_branch
   :worker_name: JiraConnect::SyncBranchWorker
   :feature_category: :integrations

app/workers/jira_connect/forward_event_worker.rb

+# frozen_string_literal: true
+
+module JiraConnect
+  class ForwardEventWorker # rubocop:disable Scalability/IdempotentWorker
+    include ApplicationWorker
+
+    queue_namespace :jira_connect
+    feature_category :integrations
+    worker_has_external_dependencies!
+
+    def perform(installation_id, base_path, event_path)
+      installation = JiraConnectInstallation.find_by_id(installation_id)
+
+      return if installation&.instance_url.nil?
+
+      proxy_url = installation.instance_url + event_path
+      qsh = Atlassian::Jwt.create_query_string_hash(proxy_url, 'POST', installation.instance_url + base_path)
+      jwt = Atlassian::Jwt.encode({ iss: installation.client_key, qsh: qsh }, installation.shared_secret)
+
+      Gitlab::HTTP.post(proxy_url, headers: { 'Authorization' => "JWT #{jwt}" })
+    ensure
+      installation.destroy if installation
+    end
+  end
+end

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -552,7 +552,7 @@ LDAP.
 If the email has changed and the DN has not, GitLab finds the user with
 the DN and update its own record of the user's email to match the one in LDAP.
 
-However, if the primary email _and_ the DN change in LDAP, then GitLab 
+However, if the primary email _and_ the DN change in LDAP, then GitLab
 has no way of identifying the correct LDAP record of the user and, as a
 result, the user is blocked. To rectify this, the user's existing
 profile must be updated with at least one of the new values (primary

doc/administration/database_load_balancing.md

@@ -109,17 +109,17 @@ the following. This balances the load between `host1.example.com` and
 Sidekiq mostly writes to the database, which means that most of its traffic hits the
 primary database.
 
-Some background jobs can use database replicas to read application state. 
+Some background jobs can use database replicas to read application state.
 This allows to offload the primary database.
 
 Load balancing is disabled by default in Sidekiq. When enabled, we can define
 [the data consistency](../development/sidekiq_style_guide.md#job-data-consistency-strategies)
 requirements for a specific job.
 
-To enable it, define the `ENABLE_LOAD_BALANCING_FOR_SIDEKIQ` variable to the environment, as shown below. 
+To enable it, define the `ENABLE_LOAD_BALANCING_FOR_SIDEKIQ` variable to the environment, as shown below.
 
 For Omnibus installations:
-               
+
 ```ruby
 gitlab_rails['env'] = {"ENABLE_LOAD_BALANCING_FOR_SIDEKIQ" => "true"}
 ```

doc/administration/geo/replication/datatypes.md

@@ -209,6 +209,6 @@ successfully, you must replicate their data using some other means.
 
 #### Limitation of verification for files in Object Storage
 
-GitLab managed Object Storage replication support [is in beta](object_storage.md#enabling-gitlab-managed-object-storage-replication). 
+GitLab managed Object Storage replication support [is in beta](object_storage.md#enabling-gitlab-managed-object-storage-replication).
 
 Locally stored files are verified but remote stored files are not.

doc/administration/geo/replication/version_specific_updates.md

@@ -13,7 +13,7 @@ for updating Geo nodes.
 
 ## Updating to GitLab 13.11
 
-We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitlab-org/gitlab/-/issues/330787) on Geo secondaries and on any GitLab instance if maintenance mode is enabled. This was caused by a regression in GitLab Workhorse. This is fixed in the [GitLab 13.11.4 patch release](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/). To avoid this issue, upgrade to GitLab 13.11.4 or later. 
+We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitlab-org/gitlab/-/issues/330787) on Geo secondaries and on any GitLab instance if maintenance mode is enabled. This was caused by a regression in GitLab Workhorse. This is fixed in the [GitLab 13.11.4 patch release](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/). To avoid this issue, upgrade to GitLab 13.11.4 or later.
 
 ## Updating to GitLab 13.9
 

doc/administration/geo/setup/database.md

@@ -31,17 +31,17 @@ A single instance database replication is easier to set up and still provides th
 as a clusterized alternative. It's useful for setups running on a single machine
 or trying to evaluate Geo for a future clusterized installation.
 
-A single instance can be expanded to a clusterized version using Patroni, which is recommended for a 
+A single instance can be expanded to a clusterized version using Patroni, which is recommended for a
 highly available architecture.
 
-Follow below the instructions on how to set up PostgreSQL replication as a single instance database. 
-Alternatively, you can look at the [Multi-node database replication](#multi-node-database-replication) 
+Follow below the instructions on how to set up PostgreSQL replication as a single instance database.
+Alternatively, you can look at the [Multi-node database replication](#multi-node-database-replication)
 instructions on setting up replication with a Patroni cluster.
 
 ### PostgreSQL replication
 
 The GitLab **primary** node where the write operations happen connects to
-the **primary** database server, and **secondary** nodes 
+the **primary** database server, and **secondary** nodes
 connect to their own database servers (which are also read-only).
 
 We recommend using [PostgreSQL replication slots](https://medium.com/@tk512/replication-slots-in-postgresql-b4b03d277c75)
@@ -112,13 +112,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    # must be present in all application nodes.
    gitlab_rails['db_password'] = '<your_password_here>'
    ```
-   
+
 1. Define a password for the database [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication).
 
    We will use the username defined in `/etc/gitlab/gitlab.rb` under the `postgresql['sql_replication_user']`
-   setting. The default value is `gitlab_replicator`, but if you changed it to something else, adapt 
+   setting. The default value is `gitlab_replicator`, but if you changed it to something else, adapt
    the instructions below.
-   
+
    Generate a MD5 hash of the desired password:
 
    ```shell
@@ -484,12 +484,12 @@ The replication process is now complete.
 ### PgBouncer support (optional)
 
 [PgBouncer](https://www.pgbouncer.org/) may be used with GitLab Geo to pool
-PostgreSQL connections, which can improve performance even when using in a 
-single instance installation. 
+PostgreSQL connections, which can improve performance even when using in a
+single instance installation.
 
 We recommend using PgBouncer if you use GitLab in a highly available  
-configuration with a cluster of nodes supporting a Geo **primary** site and 
-two other clusters of nodes supporting a Geo **secondary** site. One for the 
+configuration with a cluster of nodes supporting a Geo **primary** site and
+two other clusters of nodes supporting a Geo **secondary** site. One for the
 main database and the other for the tracking database. For more information,
 see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
 
@@ -505,7 +505,7 @@ If you still haven't [migrated from repmgr to Patroni](#migrating-from-repmgr-to
 
 Patroni is the official replication management solution for Geo. It
 can be used to build a highly available cluster on the **primary** and a **secondary** Geo site.
-Using Patroni on a **secondary** site is optional and you don't have to use the same amount of 
+Using Patroni on a **secondary** site is optional and you don't have to use the same amount of
 nodes on each Geo site.
 
 For instructions about how to set up Patroni on the primary site, see the
@@ -515,7 +515,7 @@ For instructions about how to set up Patroni on the primary site, see the
 
 In a Geo secondary site, the main PostgreSQL database is a read-only replica of the primary site’s PostgreSQL database.
 
-If you are currently using `repmgr` on your Geo primary site, see [these instructions](#migrating-from-repmgr-to-patroni) 
+If you are currently using `repmgr` on your Geo primary site, see [these instructions](#migrating-from-repmgr-to-patroni)
 for migrating from `repmgr` to Patroni.
 
 A production-ready and secure setup requires at least:
@@ -526,9 +526,9 @@ A production-ready and secure setup requires at least:
 - 1 internal load-balancer _(primary site only)_
 
 The internal load balancer provides a single endpoint for connecting to the Patroni cluster's leader whenever a new leader is
-elected, and it is required for enabling cascading replication from the secondary sites. 
+elected, and it is required for enabling cascading replication from the secondary sites.
 
-Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni) 
+Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni)
 and other database best practices.
 
 ##### Step 1. Configure Patroni permanent replication slot on the primary site
@@ -790,13 +790,13 @@ Secondary sites use a separate PostgreSQL installation as a tracking database to
 keep track of replication status and automatically recover from potential replication issues.
 Omnibus automatically configures a tracking database when `roles(['geo_secondary_role'])` is set.
 
-If you want to run this database in a highly available configuration, don't use the `geo_secondary_role` above. 
+If you want to run this database in a highly available configuration, don't use the `geo_secondary_role` above.
 Instead, follow the instructions below.
 
 A production-ready and secure setup requires at least three Consul nodes, two
 Patroni nodes and one PgBouncer node on the secondary site.
 
-Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni) 
+Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni)
 and other database best practices.
 
 #### Step 1. Configure a PgBouncer node on the secondary site

doc/administration/geo/setup/external_database.md

@@ -208,8 +208,8 @@ the tracking database on port 5432.
 1. Set up PostgreSQL according to the
    [database requirements document](../../../install/requirements.md#database).
 1. Set up a `gitlab_geo` user with a password of your choice, create the `gitlabhq_geo_production` database, and make the user an owner of the database. You can see an example of this setup in the [installation from source documentation](../../../install/installation.md#6-database).
-1. If you are **not** using a cloud-managed PostgreSQL database, ensure that your secondary 
-   node can communicate with your tracking database by manually changing the 
+1. If you are **not** using a cloud-managed PostgreSQL database, ensure that your secondary
+   node can communicate with your tracking database by manually changing the
    `pg_hba.conf` that is associated with your tracking database.
    Remember to restart PostgreSQL afterwards for the changes to take effect:
 

doc/administration/job_logs.md

@@ -145,7 +145,7 @@ in `/var/opt/gitlab/gitlab-ci/builds` by Omnibus GitLab. After the job completes
 a background job archives the job log. The log is moved to `/var/opt/gitlab/gitlab-rails/shared/artifacts/`
 by default, or to object storage if configured.
 
-In a [scaled-out architecture](reference_architectures/index.md) with Rails and Sidekiq running on more than one 
+In a [scaled-out architecture](reference_architectures/index.md) with Rails and Sidekiq running on more than one
 server, these two locations on the filesystem have to be shared using NFS.
 
 To eliminate both filesystem requirements:

doc/administration/operations/extra_sidekiq_processes.md

@@ -171,7 +171,7 @@ When disabling `sidekiq_cluster`, you must copy your configuration for
 `sidekiq_cluster` is overridden by the options for `sidekiq` when
 setting `sidekiq['cluster'] = true`.
 
-When using this feature, the service called `sidekiq` is now 
+When using this feature, the service called `sidekiq` is now
 running `sidekiq-cluster`.
 
 The [concurrency](#manage-concurrency) and other options configured

doc/administration/packages/container_registry.md

@@ -1359,7 +1359,7 @@ For Omnibus installations:
    [image upgrade](#images-upgrade)) steps. You should [stop](https://docs.gitlab.com/omnibus/maintenance/#starting-and-stopping)
    the registry service before replacing its binary and start it right after. No registry
    configuration changes are required.
- 
+
 #### Source installations
 
 For source installations, locate your `registry` binary and temporarily replace it with the one

doc/administration/reference_architectures/10k_users.md

@@ -1605,7 +1605,7 @@ To configure the Praefect nodes, on each one:
 1. Praefect requires to run some database migrations, much like the main GitLab application. For this
    you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
    must be configured first before the others as follows:
-   
+
    1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
    1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
@@ -1613,7 +1613,7 @@ To configure the Praefect nodes, on each one:
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
-   
+
    1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
       to run the Praefect database migrations.
 

doc/administration/reference_architectures/25k_users.md

@@ -1623,7 +1623,7 @@ the file of the same name on this server. If this is the first Omnibus node you
 1. Praefect requires to run some database migrations, much like the main GitLab application. For this
    you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
    must be configured first before the others as follows:
-   
+
    1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
    1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
@@ -1631,7 +1631,7 @@ the file of the same name on this server. If this is the first Omnibus node you
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
-   
+
    1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
       to run the Praefect database migrations.
 

doc/administration/reference_architectures/3k_users.md

@@ -829,7 +829,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    username of `gitlab_replicator` (recommended). The command will request a password
    and a confirmation. Use the value that is output by this command in the next step
    as the value of `<postgresql_replication_password_hash>`:
-   
+
    ```shell
    sudo gitlab-ctl pg-password-md5 gitlab_replicator
    ```
@@ -1328,7 +1328,7 @@ the file of the same name on this server. If this is the first Omnibus node you
 1. Praefect requires to run some database migrations, much like the main GitLab application. For this
    you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
    must be configured first before the others as follows:
-   
+
    1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
    1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
@@ -1336,7 +1336,7 @@ the file of the same name on this server. If this is the first Omnibus node you
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
-   
+
    1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
       to run the Praefect database migrations.
 

doc/administration/reference_architectures/50k_users.md

@@ -1627,7 +1627,7 @@ the file of the same name on this server. If this is the first Omnibus node you
 1. Praefect requires to run some database migrations, much like the main GitLab application. For this
    you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
    must be configured first before the others as follows:
-   
+
    1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
    1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
@@ -1635,7 +1635,7 @@ the file of the same name on this server. If this is the first Omnibus node you
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
-   
+
    1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
       to run the Praefect database migrations.
 

doc/administration/reference_architectures/5k_users.md

@@ -1320,7 +1320,7 @@ the file of the same name on this server. If this is the first Omnibus node you
 1. Praefect requires to run some database migrations, much like the main GitLab application. For this
    you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
    must be configured first before the others as follows:
-   
+
    1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
    1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
@@ -1328,7 +1328,7 @@ the file of the same name on this server. If this is the first Omnibus node you
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
-   
+
    1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
       to run the Praefect database migrations.
 

doc/administration/repository_storage_paths.md

@@ -155,5 +155,5 @@ often it is chosen. That is, `(storage weight) / (sum of all weights) * 100 = ch
 
 ## Move repositories
 
-To move a repository to a different repository storage (for example, from `default` to `storage2`), use the 
+To move a repository to a different repository storage (for example, from `default` to `storage2`), use the
 same process as [migrating to Gitaly Cluster](gitaly/praefect.md#migrate-to-gitaly-cluster).

doc/administration/troubleshooting/debug.md

@@ -224,7 +224,7 @@ gitlab_rails['env'] = {
 }
 ```
 
-For source installations, set the environment variable.   
+For source installations, set the environment variable.
 Refer to [Puma Worker timeout](https://docs.gitlab.com/omnibus/settings/puma.html#worker-timeout).
 
 [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -348,10 +348,10 @@ end
 puts "#{artifact_storage} bytes"
 ```
 
-### Identify deploy keys associated with blocked and non-member users 
+### Identify deploy keys associated with blocked and non-member users
 
-When the user who created a deploy key is blocked or removed from the project, the key 
-can no longer be used to push to protected branches in a private project (see [issue #329742](https://gitlab.com/gitlab-org/gitlab/-/issues/329742)). 
+When the user who created a deploy key is blocked or removed from the project, the key
+can no longer be used to push to protected branches in a private project (see [issue #329742](https://gitlab.com/gitlab-org/gitlab/-/issues/329742)).
 The following script identifies unusable deploy keys:
 
 ```ruby

doc/api/graphql/getting_started.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 This guide demonstrates basic usage of the GitLab GraphQL API.
 
-Read the [GraphQL API style guide](../../development/api_graphql_styleguide.md) 
+Read the [GraphQL API style guide](../../development/api_graphql_styleguide.md)
 for implementation details aimed at developers who wish to work on developing
 the API itself.
 

doc/api/graphql/reference/index.md

@@ -11205,6 +11205,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="pipelinesecurityreportfindingsreporttype"></a>`reportType` | [`[String!]`](#string) | Filter vulnerability findings by report type. |
 | <a id="pipelinesecurityreportfindingsscanner"></a>`scanner` | [`[String!]`](#string) | Filter vulnerability findings by Scanner.externalId. |
 | <a id="pipelinesecurityreportfindingsseverity"></a>`severity` | [`[String!]`](#string) | Filter vulnerability findings by severity. |
+| <a id="pipelinesecurityreportfindingsstate"></a>`state` | [`[VulnerabilityState!]`](#vulnerabilitystate) | Filter vulnerability findings by state. |
 
 ##### `Pipeline.testSuite`
 

doc/api/index.md

@@ -61,7 +61,7 @@ version number.
 
 New features and bug fixes are released in tandem with GitLab. Apart
 from incidental patch and security releases, GitLab is released on the 22nd of each
-month. Major API version changes, and removal of entire API versions, are done in tandem 
+month. Major API version changes, and removal of entire API versions, are done in tandem
 with major GitLab releases.
 
 All deprecations and changes between versions are in the documentation.

doc/api/repositories.md

@@ -313,7 +313,7 @@ Supported attributes:
 
 WARNING:
 GitLab treats trailers case-sensitively. If you set the `trailer` field to
-`Example`, GitLab _won't_ include commits that use the trailer `example`, 
+`Example`, GitLab _won't_ include commits that use the trailer `example`,
 `eXaMpLE`, or anything else that isn't _exactly_ `Example`.
 
 If the `from` attribute is unspecified, GitLab uses the Git tag of the last

doc/api/status_checks.md

@@ -12,7 +12,7 @@ type: reference, api
 > - It's disabled on GitLab.com.
 > - It's not recommended for production use.
 > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-external-status-checks).
- 
+
 WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
 

doc/ci/docker/using_docker_build.md

@@ -25,7 +25,7 @@ To enable Docker commands for your CI/CD jobs, you can use:
 If you don't want to execute a runner in privileged mode,
 but want to use `docker build`, you can also [use kaniko](using_kaniko.md).
 
-If you are using shared runners on GitLab.com, 
+If you are using shared runners on GitLab.com,
 [learn more about how these runners are configured](../runners/index.md).
 
 ### Use the shell executor

doc/ci/examples/authenticating-with-hashicorp-vault/index.md

@@ -204,7 +204,7 @@ read_secrets:
 ```
 
 NOTE:
-If you're using a Vault instance provided by HashiCorp Cloud Platform, 
+If you're using a Vault instance provided by HashiCorp Cloud Platform,
 you need to export the `VAULT_NAMESPACE` variable. Its default value is `admin`.
 
 ![read_secrets staging](img/vault-read-secrets-staging.png)

doc/ci/runners/build_cloud/linux_build_cloud.md

@@ -27,7 +27,6 @@ Below are the shared runners settings.
 
 | Setting                               | GitLab.com                                        | Default    |
 | -----------                           | -----------------                                 | ---------- |
-| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) | [Runner versions dashboard](https://dashboards.gitlab.net/d/ci-runners-deployment/ci-runners-deployment-overview?orgId=1&refresh=1m) | - |
 | Executor                              | `docker+machine`                                  | -          |
 | Default Docker image                  | `ruby:2.5`                                        | -          |
 | `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true`          | `false`    |

doc/development/api_graphql_styleguide.md

@@ -685,7 +685,7 @@ The API will also accept these types in the query signature for the argument:
 - `IntegrationsPrometheusID`
 
 NOTE:
-Although queries that use the old type (`PrometheusServiceID` in this example) will be 
+Although queries that use the old type (`PrometheusServiceID` in this example) will be
 considered valid and executable by the API, validator tools will consider them to be invalid.
 This is because we are deprecating using a bespoke method outside of the
 [`@deprecated` directive](https://spec.graphql.org/June2018/#sec--deprecated), so validators are not

doc/development/background_migrations.md

@@ -7,9 +7,9 @@ info: "See the Technical Writers assigned to Development Guidelines: https://abo
 
 # Background migrations
 
-Background migrations should be used to perform data migrations whenever a 
-migration exceeds [the time limits in our guidelines](database_review.md#timing-guidelines-for-migrations). For example, you can use background 
-migrations to migrate data that's stored in a single JSON column 
+Background migrations should be used to perform data migrations whenever a
+migration exceeds [the time limits in our guidelines](database_review.md#timing-guidelines-for-migrations). For example, you can use background
+migrations to migrate data that's stored in a single JSON column
 to a separate table instead.
 
 If the database cluster is considered to be in an unhealthy state, background
@@ -17,7 +17,7 @@ migrations automatically reschedule themselves for a later point in time.
 
 ## When To Use Background Migrations
 
-You should use a background migration when you migrate _data_ in tables that have 
+You should use a background migration when you migrate _data_ in tables that have
 so many rows that the process would exceed [the time limits in our guidelines](database_review.md#timing-guidelines-for-migrations) if performed using a regular Rails migration.
 
 - Background migrations should be used when migrating data in [high-traffic tables](migration_style_guide.md#high-traffic-tables).

doc/development/changelog.md

@@ -81,7 +81,7 @@ EE: true
 
 - Any change that introduces a database migration, whether it's regular, post,
   or data migration, **must** have a changelog entry, even if it is behind a
-  disabled feature flag. 
+  disabled feature flag.
 - [Security fixes](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md)
   **must** have a changelog entry, with `Changelog` trailer set to `security`.
 - Any user-facing change **must** have a changelog entry. Example: "GitLab now

doc/development/database/pagination_performance_guidelines.md

@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ---
 
 # Pagination performance guidelines
-                                                                                   
+
 The following document gives a few ideas for improving the pagination (sorting) performance. These apply both on [offset](pagination_guidelines.md#offset-pagination) and [keyset](pagination_guidelines.md#keyset-pagination) paginations.
 
 ## Tie-breaker column

doc/development/database/rename_database_tables.md

@@ -81,7 +81,7 @@ Execute a standard migration (not a post-migration):
 when naming indexes, so there is a possibility that not all indexes are properly renamed. After running
 the migration locally, check if there are inconsistently named indexes (`db/structure.sql`). Those can be
 renamed manually in a separate migration, which can be also part of the release M.N+1.
-- Foreign key columns might still contain the old table name. For smaller tables, follow our [standard column 
+- Foreign key columns might still contain the old table name. For smaller tables, follow our [standard column
 rename process](../avoiding_downtime_in_migrations.md#renaming-columns)
 - Avoid renaming database tables which are using with triggers.
 - Table modifications (add or remove columns) are not allowed during the rename process, please make sure that all changes to the table happen before the rename migration is started (or in the next release).

doc/development/documentation/testing.md

@@ -221,7 +221,7 @@ guidelines:
 | *correctly-capitalized* name of a product or service | Add the word to the [vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt). |
 | name of a person                                     | Remove the name if it's not needed, or [add the vale exception code in-line](#disable-vale-tests). |
 | a command, variable, code, or similar                | Put it in backticks or a code block. For example: ``The git clone command can be used with the CI_COMMIT_BRANCH variable.`` -> ``The `git clone` command can be used with the `CI_COMMIT_BRANCH` variable.`` |
-| UI text from GitLab                                  | Verify it correctly matches the UI, then: <ul><li>If it does not match the UI, update it.</li><li>If it matches the UI, but the UI seems incorrect, create an issue to see if the UI needs to be fixed.</li><li>If it matches the UI and seems correct, add it to the [vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt).</li></ul> |
+| UI text from GitLab                                  | Verify it correctly matches the UI, then: If it does not match the UI, update it. If it matches the UI, but the UI seems incorrect, create an issue to see if the UI needs to be fixed. If it matches the UI and seems correct, add it to the [vale spelling exceptions list](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/spelling-exceptions.txt). |
 | UI text from a third-party product                   | Rewrite the sentence to avoid it, or [add the vale exception code in-line](#disable-vale-tests). |
 
 ### Install linters

doc/development/fe_guide/performance.md

@@ -256,17 +256,17 @@ We support two types of prefetching for the chunks:
 - The [`prefetch` link type](https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/prefetch)
   is used to prefetch a chunk for the future navigation
 - The [`preload` link type](https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preloadh)
-  is used to prefetch a chunk that is crucial for the current navigation but is not 
+  is used to prefetch a chunk that is crucial for the current navigation but is not
   discovered until later in the rendering process
 
-Both `prefetch` and `preload` links bring the loading performance benefit to the pages. Both are 
+Both `prefetch` and `preload` links bring the loading performance benefit to the pages. Both are
 fetched asynchronously, but contrary to [deferring the loading](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attr-defer)
 of the assets which is used for other JavaScript resources in the product by default, `prefetch` and
-`preload` neither parse nor execute the fetched script unless explicitly imported in any JavaScript 
-module. This allows to cache the fetched resources without blocking the execution of the 
+`preload` neither parse nor execute the fetched script unless explicitly imported in any JavaScript
+module. This allows to cache the fetched resources without blocking the execution of the
 remaining page resources.
 
-To prefetch a JavaScript chunk in a HAML view, `:prefetch_asset_tags` with the combination of 
+To prefetch a JavaScript chunk in a HAML view, `:prefetch_asset_tags` with the combination of
 the `webpack_preload_asset_tag` helper is provided:
 
 ```javascript
@@ -280,8 +280,8 @@ This snippet will add a new `<link rel="preload">` element into the resulting HT
 <link rel="preload" href="/assets/webpack/monaco.chunk.js" as="script" type="text/javascript">
 ```
 
-By default, `webpack_preload_asset_tag` will `preload` the chunk. You don't need to worry about 
-`as` and `type` attributes for preloading the JavaScript chunks. However, when a chunk is not 
+By default, `webpack_preload_asset_tag` will `preload` the chunk. You don't need to worry about
+`as` and `type` attributes for preloading the JavaScript chunks. However, when a chunk is not
 critical, for the current navigation, one has to explicitly request `prefetch`:
 
 ```javascript

doc/development/fe_guide/storybook.md

@@ -43,7 +43,7 @@ To add a story:
     ```
 
 1. Write the story as per the [official Storybook instructions](https://storybook.js.org/docs/vue/writing-stories/introduction)
-   
+
    Notes:
    - Specify the `title` field of the story as the component's file path from the `javascripts/` directory,
      e.g. if the component is located at `app/assets/javascripts/vue_shared/components/todo_button.vue`, specify the `title` as

doc/development/foreign_keys.md

@@ -28,7 +28,7 @@ Guide](migration_style_guide.md) for more information.
 
 Keep in mind that you can only safely add foreign keys to existing tables after
 you have removed any orphaned rows. The method `add_concurrent_foreign_key`
-does not take care of this so you'll need to do so manually. See 
+does not take care of this so you'll need to do so manually. See
 [adding foreign key constraint to an existing column](database/add_foreign_key_to_existing_column.md).
 
 ## Cascading Deletes

doc/development/testing_guide/end_to_end/index.md

@@ -100,7 +100,7 @@ You may have noticed that we use `gitlab-org/build/omnibus-gitlab-mirror` instea
 This is due to technical limitations in the GitLab permission model: the ability to run a pipeline
 against a protected branch is controlled by the ability to push/merge to this branch.
 This means that for developers to be able to trigger a pipeline for the default branch in
-`gitlab-org/omnibus-gitlab`/`gitlab-org/gitlab-qa`, they would need to have the 
+`gitlab-org/omnibus-gitlab`/`gitlab-org/gitlab-qa`, they would need to have the
 [Maintainer role](../../../user/permissions.md) for those projects.
 For security reasons and implications, we couldn't open up the default branch to all the Developers.
 Hence we created these mirrors where Developers and Maintainers are allowed to push/merge to the default branch.

doc/topics/autodevops/quick_start_guide.md

@@ -131,7 +131,7 @@ Follow these steps to configure the Base Domain where your apps will be accessib
 
 1. A few minutes after you install NGINX, the load balancer obtains an IP address, and you can
    get the external IP address with the following command:
-   
+
    ```shell
    kubectl get service ingress-nginx-ingress-controller -n gitlab-managed-apps -ojson | jq -r '.status.loadBalancer.ingress[].ip'
    ```

doc/topics/git/numerous_undo_possibilities_in_git/index.md

@@ -249,7 +249,7 @@ commits `A-B-C-D` and you want to modify something introduced in commit `B`.
    ```
 
    A list of commits is displayed in your editor.
-   
+
 1. In front of commit `B`, replace `pick` with `edit`.
 1. Leave the default, `pick`, for all other commits.
 1. Save and exit the editor.

doc/topics/gitlab_flow.md

@@ -152,7 +152,7 @@ After the assigned person feels comfortable with the result, they can merge the
 If the assigned person does not feel comfortable, they can request more changes or close the merge request without merging.
 
 In GitLab, it is common to protect the long-lived branches, such as the `main` branch, so [most developers can't modify them](../user/permissions.md).
-So, if you want to merge into a protected branch, assign your merge request to someone with the 
+So, if you want to merge into a protected branch, assign your merge request to someone with the
 [Maintainer role](../user/permissions.md).
 
 After you merge a feature branch, you should remove it from the source control software.

doc/user/admin_area/moderate_users.md

@@ -145,7 +145,7 @@ A deactivated user can also activate their account themselves by logging back in
 GitLab administrators can ban users.
 
 NOTE:
-This feature is behind a feature flag that is disabled by default. GitLab administrators 
+This feature is behind a feature flag that is disabled by default. GitLab administrators
 with access to the GitLab Rails console can [enable](../../administration/feature_flags.md)
 this feature for your GitLab instance.
 

doc/user/application_security/dast/browser_based.md

@@ -63,8 +63,8 @@ The browser-based crawler can be configured using CI/CD variables.
 
 The [DAST variables](index.md#available-cicd-variables) `SECURE_ANALYZERS_PREFIX`, `DAST_FULL_SCAN_ENABLED`, `DAST_AUTO_UPDATE_ADDONS`, `DAST_EXCLUDE_RULES`, `DAST_REQUEST_HEADERS`, `DAST_HTML_REPORT`, `DAST_MARKDOWN_REPORT`, `DAST_XML_REPORT`,
 `DAST_AUTH_URL`, `DAST_USERNAME`, `DAST_PASSWORD`, `DAST_USERNAME_FIELD`, `DAST_PASSWORD_FIELD`, `DAST_FIRST_SUBMIT_FIELD`, `DAST_SUBMIT_FIELD`, `DAST_EXCLUDE_URLS`, `DAST_AUTH_VERIFICATION_URL`, `DAST_BROWSER_AUTH_VERIFICATION_SELECTOR`, `DAST_BROWSER_AUTH_VERIFICATION_LOGIN_FORM`, `DAST_BROWSER_AUTH_REPORT`,
-`DAST_INCLUDE_ALPHA_VULNERABILITIES`, `DAST_PATHS_FILE`, `DAST_PATHS`, `DAST_ZAP_CLI_OPTIONS`, and `DAST_ZAP_LOG_CONFIGURATION` are also compatible with browser-based crawler scans.   
- 
+`DAST_INCLUDE_ALPHA_VULNERABILITIES`, `DAST_PATHS_FILE`, `DAST_PATHS`, `DAST_ZAP_CLI_OPTIONS`, and `DAST_ZAP_LOG_CONFIGURATION` are also compatible with browser-based crawler scans.
+
 ## Vulnerability detection
 
 While the browser-based crawler crawls modern web applications efficiently, vulnerability detection is still managed by the standard DAST/Zed Attack Proxy (ZAP) solution.

doc/user/application_security/dast/index.md

@@ -791,9 +791,9 @@ In order of preference, it is recommended to choose as selectors:
 
 - `id` fields. These are generally unique on a page, and rarely change.
 - `name` fields. These are generally unique on a page, and rarely change.
-- `class` values specific to the field, such as the selector `"css:.username"` for the `username` class on the username field.   
+- `class` values specific to the field, such as the selector `"css:.username"` for the `username` class on the username field.
 - Presence of field specific data attributes, such as the selector, `"css:[data-username]"` when the `data-username` field has any value on the username field.
-- Multiple `class` hierarchy values, such as the selector `"css:.login-form .username"` when there are multiple elements with class `username` but only one nested inside the element with the class `login-form`.   
+- Multiple `class` hierarchy values, such as the selector `"css:.login-form .username"` when there are multiple elements with class `username` but only one nested inside the element with the class `login-form`.
 
 When using selectors to locate specific fields we recommend you avoid searching on:
 

doc/user/application_security/dependency_list/index.md

@@ -13,7 +13,7 @@ Use the dependency list to review your project's dependencies and key
 details about those dependencies, including their known vulnerabilities. It is a collection of dependencies in your project, including existing and new findings. To see the dependency list, go to your project and select **Security & Compliance > Dependency List**.
 This information is sometimes referred to as a Software Bill of Materials or SBoM / BOM.
 
-The dependency list only shows the results of the last successful pipeline to run on the default branch. This is why we recommend not changing the default behavior of allowing the secure jobs to fail. 
+The dependency list only shows the results of the last successful pipeline to run on the default branch. This is why we recommend not changing the default behavior of allowing the secure jobs to fail.
 
 ## Prerequisites
 

doc/user/application_security/sast/index.md

@@ -512,8 +512,8 @@ Some analyzers can be customized with CI/CD variables.
 | `SBT_PATH`                  | SpotBugs   | Path to the `sbt` executable.                                                                                                                                                                                                      |
 | `FAIL_NEVER`                | SpotBugs   | Set to `1` to ignore compilation failure.                                                                                                                                                                                          |
 | `SAST_GOSEC_CONFIG`         | Gosec      | **{warning}** **[Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/328301)** in GitLab 14.0 - use custom rulesets instead. Path to configuration for Gosec (optional).                                                                                                                                                                                        |
-| `PHPCS_SECURITY_AUDIT_PHP_EXTENSIONS` | phpcs-security-audit | Comma separated list of additional PHP Extensions.                                                                                                                                                             |                                                 
-| `SAST_DISABLE_BABEL`        | NodeJsScan | **{warning}** **[Removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64025)** in GitLab 13.5 |               
+| `PHPCS_SECURITY_AUDIT_PHP_EXTENSIONS` | phpcs-security-audit | Comma separated list of additional PHP Extensions.                                                                                                                                                             |
+| `SAST_DISABLE_BABEL`        | NodeJsScan | **{warning}** **[Removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64025)** in GitLab 13.5 |
 | `SAST_SEMGREP_METRICS` | Semgrep | Set to `"false"` to disable sending anonymized scan metrics to [r2c](https://r2c.dev/). Default: `true`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330565) in GitLab 14.0.      |
 
 #### Custom CI/CD variables

doc/user/application_security/vulnerability_report/index.md

@@ -128,11 +128,11 @@ To view the relevant file, select the filename in the vulnerability's details.
 ## View issues raised for a vulnerability
 
 The **Activity** column indicates the number of issues that have been created for the vulnerability.
-Hover over an **Activity** entry and select a link go to that issue. The status of whether the issue is open or closed also displays in the hover menu. 
+Hover over an **Activity** entry and select a link go to that issue. The status of whether the issue is open or closed also displays in the hover menu.
 
 ![Display attached issues](img/vulnerability_list_table_v13_9.png)
 
-If Jira issue support is enabled, the issue link found in the Activity entry links out to the issue in Jira. Unlike GitLab issues, the status of whether a Jira issue is Open or Closed does not display in the GitLab UI. 
+If Jira issue support is enabled, the issue link found in the Activity entry links out to the issue in Jira. Unlike GitLab issues, the status of whether a Jira issue is Open or Closed does not display in the GitLab UI.
 
 ## Change status of vulnerabilities
 

doc/user/clusters/management_project_template.md

@@ -18,7 +18,7 @@ need, or even add new ones that are not built-in.
 
 ## How to use this template
 
-1. Create a new project, choosing "GitLab Cluster Management" from the list of [built-in project templates](../project/working_with_projects.md#built-in-templates). 
+1. Create a new project, choosing "GitLab Cluster Management" from the list of [built-in project templates](../project/working_with_projects.md#built-in-templates).
 1. Make this project a [cluster management project](management_project.md).
 1. If you used the [GitLab Managed Apps](applications.md), refer to
    [Migrating from GitLab Managed Apps](migrating_from_gma_to_project_template.md).
@@ -37,10 +37,10 @@ In the repository of the newly-created project, you will find:
 The base image used in your pipeline is built by the [cluster-applications](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications)
 project. This image consists of a set of Bash utility scripts to support [Helm v3 releases](https://helm.sh/docs/intro/using_helm/#three-big-concepts):
 
-- `gl-fail-if-helm2-releases-exist {namespace}`: It tries to detect whether you have apps deployed through Helm v2 
-  releases for a given namespace. If so, it will fail the pipeline and ask you to manually 
+- `gl-fail-if-helm2-releases-exist {namespace}`: It tries to detect whether you have apps deployed through Helm v2
+  releases for a given namespace. If so, it will fail the pipeline and ask you to manually
   [migrate your Helm v2 releases to Helm v3](https://helm.sh/docs/topics/v2_v3_migration/).
-- `gl-ensure-namespace {namespace}`: It creates the given namespace if it does not exist and adds the necessary label 
+- `gl-ensure-namespace {namespace}`: It creates the given namespace if it does not exist and adds the necessary label
   for the [Cilium](https://github.com/cilium/cilium/) app network policies to work.
 - `gl-adopt-resource-with-helm-v3 {arguments}`: Used only internally in the [cert-manager's](https://cert-manager.io/) Helmfile to
   facilitate the GitLab Managed Apps adoption.
@@ -50,7 +50,7 @@ project. This image consists of a set of Bash utility scripts to support [Helm v
 
 #### The main `helmfile.yml` file
 
-This file has a list of paths to other Helmfiles for each app. They're all commented out by default, so you must uncomment 
+This file has a list of paths to other Helmfiles for each app. They're all commented out by default, so you must uncomment
 the paths for the apps that you would like to manage.
 
 By default, each `helmfile.yaml` in these sub-paths will have the attribute `installed: true`, which signifies that everytime
@@ -58,7 +58,7 @@ the pipeline runs, Helmfile will try to either install or update your apps accor
 cluster and Helm releases. If you change this attribute to `installed: false`, Helmfile will try to uninstall this app
 from your cluster. [Read more](https://github.com/roboll/helmfile) about how Helmfile works.
 
-Furthermore, each app has an `applications/{app}/values.yaml` file. This is the 
+Furthermore, each app has an `applications/{app}/values.yaml` file. This is the
 place where you can define some default values for your app's Helm chart. Some apps will already have defaults
 pre-defined by GitLab.
 
@@ -82,5 +82,5 @@ The [built-in supported applications](https://gitlab.com/gitlab-org/project-temp
 
 ### Migrating from GitLab Managed Apps
 
-If you had GitLab Managed Apps, either One-Click or CI/CD install, read the docs on how to 
+If you had GitLab Managed Apps, either One-Click or CI/CD install, read the docs on how to
 [migrate from GitLab Managed Apps to project template](migrating_from_gma_to_project_template.md)

doc/user/clusters/migrating_from_gma_to_project_template.md

@@ -35,9 +35,9 @@ The [GitLab Managed Apps](applications.md) are deprecated in GitLab 14.0. To mig
    applications that you would like to manage with this project. Although you could uncomment all the ones you want to
    managed at once, we recommend you repeat the following steps separately for each app, so you do not get lost during
    the process.
-1. Edit the associated `applications/{app}/helmfiles.yaml` to match the chart version currently deployed 
+1. Edit the associated `applications/{app}/helmfiles.yaml` to match the chart version currently deployed
    for your app. Take a GitLab Runner Helm v3 release as an example:
-   
+
    The following command lists the releases and their versions:
 
    ```shell
@@ -83,7 +83,7 @@ The [GitLab Managed Apps](applications.md) are deprecated in GitLab 14.0. To mig
 1. After following all the previous steps, [run a pipeline manually](../../ci/pipelines/index.md#run-a-pipeline-manually)
    and watch the `apply` job logs to see if any of your applications were successfully detected, installed, and whether they got any
    unexpected updates.
-   
+
    Some annotation checksums are expected to be updated, as well as this attribute:
 
    ```diff

doc/user/discussions/index.md

@@ -52,7 +52,7 @@ To create a thread by replying to a comment:
    ![Reply to comment button](img/reply_to_comment_button.png)
 
    The reply area is displayed.
-   
+
 1. Type your reply.
 1. Select **Comment** or **Add comment now** (depending on where in the UI you are replying).
 
@@ -81,7 +81,7 @@ A threaded comment is created.
 ## Reply to a comment by sending email
 
 If you have ["reply by email"](../../administration/reply_by_email.md) configured,
-you can reply to comments by sending an email. 
+you can reply to comments by sending an email.
 
 - When you reply to a standard comment, another standard comment is created.
 - When you reply to a threaded comment, it creates a reply in the thread.

doc/user/group/saml_sso/index.md

@@ -330,11 +330,11 @@ Ensure your SAML identity provider sends an attribute statement named `Groups` o
 
 NOTE:
 To inspect the SAML response, you can use one of these [SAML debugging tools](#saml-debugging-tools).
-Also note that the value for `Groups` or `groups` in the SAML reponse can be either the group name or 
+Also note that the value for `Groups` or `groups` in the SAML reponse can be either the group name or
 the group ID depending what the IdP sends to GitLab.
 
 When SAML SSO is enabled for the top-level group, `Maintainer` and `Owner` level users
-see a new menu item in group **Settings > SAML Group Links**. You can configure one or more **SAML Group Links** to map 
+see a new menu item in group **Settings > SAML Group Links**. You can configure one or more **SAML Group Links** to map
 a SAML identity provider group name to a GitLab Access Level. This can be done for the parent group or the subgroups.
 
 To link the SAML groups from the `saml:AttributeStatement` example above:

doc/user/group/value_stream_analytics/index.md

@@ -346,7 +346,7 @@ In this example, we'd like to measure times for deployment from a staging enviro
 After you create a value stream, you can customize it to suit your purposes. To edit a value stream:
 
 1. Go to your group and select **Analytics > Value Stream**.
-1. Find and select the relevant value stream from the value stream dropdown. 
+1. Find and select the relevant value stream from the value stream dropdown.
 1. Next to the value stream dropdown, select **Edit**.
    The edit form is populated with the value stream details.
 1. Optional:

doc/user/packages/container_registry/index.md

@@ -332,7 +332,7 @@ If you forget to set the service alias, the `docker:19.03.12` image is unable to
 error during connect: Get http://docker:2376/v1.39/info: dial tcp: lookup docker on 192.168.0.1:53: no such host
 ```
 
-### Using a Docker-in-Docker image with Dependency Proxy 
+### Using a Docker-in-Docker image with Dependency Proxy
 
 To use your own Docker images with Dependency Proxy, follow these steps
 in addition to the steps in the

doc/user/packages/npm_registry/index.md

@@ -536,7 +536,7 @@ If you get this error, one of the following problems could be causing it.
 
 #### Package name does not meet the naming convention
 
-Your package name may not meet the 
+Your package name may not meet the
 [`@scope/package-name` package naming convention](#package-naming-convention).
 
 Ensure the name meets the convention exactly, including the case.
@@ -544,10 +544,10 @@ Then try to publish again.
 
 #### Package already exists
 
-Your package has already been published to another project in the same 
+Your package has already been published to another project in the same
 root namespace and therefore cannot be published again using the same name.
 
-This is also true even if the prior published package shares the same name, 
+This is also true even if the prior published package shares the same name,
 but not the version.
 
 ### `npm publish` returns `npm ERR! 500 Internal Server Error - PUT`

doc/user/packages/package_registry/index.md

@@ -94,7 +94,7 @@ To delete package files in the UI, from your group or project:
 1. Go to **Packages & Registries > Package Registry**.
 1. Find the name of the package you want to delete.
 1. Select the package to view additional details.
-1. Find the name of the file you would like to delete. 
+1. Find the name of the file you would like to delete.
 1. Expand the ellipsis and select **Delete file**.
 
 The package files are permanently deleted.

doc/user/profile/account/two_factor_authentication.md

@@ -507,7 +507,7 @@ If you are receiving an `invalid pin code` error, this may indicate that there i
 
 To avoid the time sync issue, enable time synchronization in the device that generates the codes. For example:
 
-- For Android (Google Authenticator): 
+- For Android (Google Authenticator):
   1. Go to the Main Menu in Google Authenticator.
   1. Select Settings.
   1. Select the Time correction for the codes.

doc/user/project/code_owners.md

@@ -30,7 +30,7 @@ As an alternative to using Code Owners for approvals, you can instead
 Code Owners allows for a version controlled, single source of
 truth file outlining the exact GitLab users or groups that
 own certain files or paths in a repository. In larger organizations
-or popular open source projects, Code Owners can help you understand 
+or popular open source projects, Code Owners can help you understand
 who to contact if you have a question about a specific portion of
 the codebase. Code Owners can also streamline the merge request approval
 process, identifying the most relevant reviewers and approvers for a

doc/user/project/import/bitbucket_server.md

@@ -36,7 +36,7 @@ created as private in GitLab as well.
 - Attachments in Markdown are not imported.
 - Task lists are not imported.
 - Emoji reactions are not imported.
-- Project filtering does not support fuzzy search (only `starts with` or `full match strings` are 
+- Project filtering does not support fuzzy search (only `starts with` or `full match strings` are
   supported).
 
 ## How it works

doc/user/project/members/index.md

@@ -24,7 +24,7 @@ To add a user to a project:
 1. Go to your project and select **Project information > Members**.
 1. On the **Invite member** tab, under **GitLab member or Email address**, type the username or email address.
    In GitLab 13.11 and later, you can [replace this form with a modal window](#add-a-member-modal-window).
-1. Select a [role](../../permissions.md). 
+1. Select a [role](../../permissions.md).
 1. Optional. Choose an expiration date. On that date, the user can no longer access the project.
 1. Select **Invite**.
 
@@ -54,7 +54,7 @@ To add groups to a project:
 
 1. Go to your project and select **Project information > Members**.
 1. On the **Invite group** tab, under **Select a group to invite**, choose a group.
-1. Select the highest max [role](../../permissions.md) for users in the group. 
+1. Select the highest max [role](../../permissions.md) for users in the group.
 1. Optional. Choose an expiration date. On that date, the user can no longer access the project.
 1. Select **Invite**.
 
@@ -156,7 +156,7 @@ You can sort members by **Account**, **Access granted**, **Max role**, or **Last
 
 ## Request access to a project
 
-GitLab users can request to become a member of a project. 
+GitLab users can request to become a member of a project.
 
 1. Go to the project you'd like to be a member of.
 1. By the project name, select **Request Access**.

doc/user/project/service_desk.md

@@ -172,16 +172,16 @@ both a [custom mailbox](#configuring-a-custom-mailbox) and a
 #### Configuring a custom mailbox
 
 NOTE:
-On GitLab.com a custom mailbox is already configured with `contact-project+%{key}@incoming.gitlab.com` as the email address, so you only have to configure the 
+On GitLab.com a custom mailbox is already configured with `contact-project+%{key}@incoming.gitlab.com` as the email address, so you only have to configure the
 [custom suffix](#configuring-a-custom-email-address-suffix) in project settings.
 
 Using the `service_desk_email` configuration, you can customize the mailbox
-used by Service Desk. This allows you to have a separate email address for 
+used by Service Desk. This allows you to have a separate email address for
 Service Desk by also configuring a [custom suffix](#configuring-a-custom-email-address-suffix)
 in project settings.
 
-The `address` must include the `+%{key}` placeholder within the 'user' 
-portion of the address, before the `@`. This is used to identify the project 
+The `address` must include the `+%{key}` placeholder within the 'user'
+portion of the address, before the `@`. This is used to identify the project
 where the issue should be created.
 
 NOTE:

ee/app/finders/security/pipeline_vulnerabilities_finder.rb

@@ -10,6 +10,10 @@
 #   params:
 #     report_type: Array<String>
 
+# DEPRECATED: This finder class is deprecated and will be removed
+# by https://gitlab.com/gitlab-org/gitlab/-/issues/334488.
+# Please inform us by adding a comment to aforementioned issue,
+# if you need to add an extra feature to this class.
 module Security
   class PipelineVulnerabilitiesFinder
     include Gitlab::Utils::StrongMemoize
@@ -24,18 +28,18 @@ module Security
     end
 
     def execute
-      findings = requested_reports.each_with_object([]) do |(type, report), findings|
+      findings = requested_reports.each_with_object([]) do |report, findings|
         raise ParseError, 'JSON parsing failed' if report.errored?
 
         normalized_findings = normalize_report_findings(
           report.findings,
-          vulnerabilities_by_finding_fingerprint(type, report))
+          vulnerabilities_by_finding_fingerprint(report))
         filtered_findings = filter(normalized_findings)
 
         findings.concat(filtered_findings)
       end
 
-      Gitlab::Ci::Reports::Security::AggregatedReport.new(requested_reports.values, sort_findings(findings))
+      Gitlab::Ci::Reports::Security::AggregatedReport.new(requested_reports, sort_findings(findings))
     end
 
     private
@@ -53,20 +57,23 @@ module Security
     end
 
     def requested_reports
-      @requested_reports ||= pipeline&.security_reports(report_types: report_types)&.reports || {}
+      @requested_reports ||= pipeline&.security_reports(report_types: report_types)&.reports&.values || []
     end
 
-    def vulnerabilities_by_finding_fingerprint(report_type, report)
-      Vulnerabilities::Finding
-        .by_project_fingerprints(report.findings.map(&:project_fingerprint))
-        .by_projects(pipeline.project)
-        .by_report_types(report_type)
-        .select(:vulnerability_id, :project_fingerprint)
-       .each_with_object({}) do |finding, hash|
-        hash[finding.project_fingerprint] = finding.vulnerability_id
+    def vulnerabilities_by_finding_fingerprint(report)
+      existing_findings_for(report).each_with_object({}) do |finding, memo|
+        memo[finding.project_fingerprint] = finding.vulnerability
       end
     end
 
+    def existing_findings_for(report)
+      Vulnerabilities::Finding.by_project_fingerprints(report.findings.map(&:project_fingerprint))
+                              .by_projects(pipeline.project)
+                              .by_report_types(report.type)
+                              .includes(:vulnerability) # rubocop:disable CodeReuse/ActiveRecord (We will remove this class)
+                              .select(:vulnerability_id, :project_fingerprint)
+    end
+
     # This finder is used for fetching vulnerabilities for any pipeline, if we used it to fetch
     # vulnerabilities for a non-default-branch, the findings will be unpersisted, so we
     # coerce the POROs into unpersisted AR records to give them a common object.
@@ -80,7 +87,7 @@ module Security
         finding = Vulnerabilities::Finding.new(finding_hash)
         # assigning Vulnerabilities to Findings to enable the computed state
         finding.location_fingerprint = report_finding.location.fingerprint
-        finding.vulnerability_id = vulnerabilities[finding.project_fingerprint]
+        finding.vulnerability = vulnerabilities[finding.project_fingerprint]
         finding.project = pipeline.project
         finding.sha = pipeline.sha
         finding.build_scanner(report_finding.scanner&.to_hash)
@@ -100,6 +107,7 @@ module Security
 
     def filter(findings)
       findings.select do |finding|
+        next unless in_selected_state?(finding)
         next if !include_dismissed? && dismissal_feedback?(finding)
         next unless confidence_levels.include?(finding.confidence)
         next unless severity_levels.include?(finding.severity)
@@ -109,8 +117,26 @@ module Security
       end
     end
 
+    def in_selected_state?(finding)
+      params[:state].blank? || states.include?(computed_finding_state(finding))
+    end
+
+    # Here we are checking the state of the `vulnerability` and preloaded `feedback` records
+    # instead of checking the `finding.state` as the `state` method of the `finding` fires
+    # an additional database query to load the `feedback` record for each `finding`.
+    def computed_finding_state(finding)
+      finding.vulnerability&.state ||
+        (dismissal_feedback?(finding) ? 'dismissed' : 'detected')
+    end
+
     def include_dismissed?
-      params[:scope] == 'all'
+      skip_scope_parameter? || params[:scope] == 'all'
+    end
+
+    # If the client explicitly asks for the dismissed findings, we shouldn't
+    # filter by the `scope` parameter as it's `skip_dismissed` by default.
+    def skip_scope_parameter?
+      params[:state].present? && states.include?('dismissed')
     end
 
     def dismissal_feedback?(finding)
@@ -145,19 +171,23 @@ module Security
     end
 
     def confidence_levels
-      Array(params.fetch(:confidence, Vulnerabilities::Finding.confidences.keys))
+      @confidence_levels ||= Array(params.fetch(:confidence, Vulnerabilities::Finding.confidences.keys))
     end
 
     def report_types
-      Array(params.fetch(:report_type, Vulnerabilities::Finding.report_types.keys))
+      @report_types ||= Array(params.fetch(:report_type, Vulnerabilities::Finding.report_types.keys))
     end
 
     def severity_levels
-      Array(params.fetch(:severity, Vulnerabilities::Finding.severities.keys))
+      @severity_levels ||= Array(params.fetch(:severity, Vulnerabilities::Finding.severities.keys))
     end
 
     def scanners
-      Array(params.fetch(:scanner, []))
+      @scanners ||= Array(params.fetch(:scanner, []))
+    end
+
+    def states
+      @state ||= Array(params.fetch(:state, Vulnerability.states.keys))
     end
   end
 end

ee/app/graphql/resolvers/pipeline_security_report_findings_resolver.rb

@@ -18,6 +18,10 @@ module Resolvers
              required: false,
              description: 'Filter vulnerability findings by Scanner.externalId.'
 
+    argument :state, [Types::VulnerabilityStateEnum],
+             required: false,
+             description: 'Filter vulnerability findings by state.'
+
     def resolve(**args)
       Security::PipelineVulnerabilitiesFinder.new(pipeline: pipeline, params: args).execute.findings
     end

ee/spec/finders/security/pipeline_vulnerabilities_finder_spec.rb

@@ -333,6 +333,74 @@ RSpec.describe Security::PipelineVulnerabilitiesFinder do
       end
     end
 
+    context 'by state' do
+      let(:params) { {} }
+      let(:aggregated_report) { described_class.new(pipeline: pipeline, params: params).execute }
+
+      subject(:finding_uuids) { aggregated_report.findings.map(&:uuid) }
+
+      let(:finding_with_feedback) { pipeline.security_reports.reports['sast'].findings.first }
+
+      before do
+        create(:vulnerability_feedback, :dismissal,
+               :sast,
+               project: project,
+               pipeline: pipeline,
+               category: finding_with_feedback.report_type,
+               project_fingerprint: finding_with_feedback.project_fingerprint,
+               vulnerability_data: finding_with_feedback.raw_metadata,
+               finding_uuid: finding_with_feedback.uuid)
+      end
+
+      context 'when the state parameter is not given' do
+        it 'returns all findings' do
+          expect(finding_uuids.length).to be(40)
+        end
+      end
+
+      context 'when the state parameter is given' do
+        let(:params) { { state: state } }
+        let(:finding_with_associated_vulnerability) { pipeline.security_reports.reports['dependency_scanning'].findings.first }
+
+        before do
+          vulnerability = create(:vulnerability, state, project: project)
+
+          create(:vulnerabilities_finding, :identifier,
+                 vulnerability: vulnerability,
+                 report_type: finding_with_associated_vulnerability.report_type,
+                 project: project,
+                 project_fingerprint: finding_with_associated_vulnerability.project_fingerprint,
+                 uuid: finding_with_associated_vulnerability.uuid)
+        end
+
+        context 'when the given state is `dismissed`' do
+          let(:state) { 'dismissed' }
+
+          it { is_expected.to match_array([finding_with_associated_vulnerability.uuid, finding_with_feedback.uuid]) }
+        end
+
+        context 'when the given state is `detected`' do
+          let(:state) { 'detected' }
+
+          it 'returns all detected findings' do
+            expect(finding_uuids.length).to be(40)
+          end
+        end
+
+        context 'when the given state is `confirmed`' do
+          let(:state) { 'confirmed' }
+
+          it { is_expected.to match_array([finding_with_associated_vulnerability.uuid]) }
+        end
+
+        context 'when the given state is `resolved`' do
+          let(:state) { 'resolved' }
+
+          it { is_expected.to match_array([finding_with_associated_vulnerability.uuid]) }
+        end
+      end
+    end
+
     context 'by all filters' do
       context 'with found entity' do
         let(:params) { { report_type: %w[sast dast container_scanning dependency_scanning], scanner: %w[bundler_audit find_sec_bugs gemnasium trivy zaproxy], scope: 'all' } }

ee/spec/graphql/resolvers/pipeline_security_report_findings_resolver_spec.rb

@@ -9,7 +9,7 @@ RSpec.describe Resolvers::PipelineSecurityReportFindingsResolver do
   let_it_be(:pipeline, reload: true) { create(:ci_pipeline, :success, project: project) }
 
   describe '#resolve' do
-    subject { resolve(described_class, obj: pipeline, args: params) }
+    subject(:resolve_query) { resolve(described_class, obj: pipeline, args: params) }
 
     let_it_be(:low_vulnerability_finding) { build(:vulnerabilities_finding, severity: :low, report_type: :dast, project: project) }
     let_it_be(:critical_vulnerability_finding) { build(:vulnerabilities_finding, severity: :critical, report_type: :sast, project: project) }
@@ -49,5 +49,19 @@ RSpec.describe Resolvers::PipelineSecurityReportFindingsResolver do
         is_expected.to contain_exactly(critical_vulnerability_finding, low_vulnerability_finding)
       end
     end
+
+    context 'when given states' do
+      let(:params) { { state: %w(detected confirmed) } }
+
+      before do
+        allow(Security::PipelineVulnerabilitiesFinder).to receive(:new).and_call_original
+      end
+
+      it 'calls the finder class with given parameters' do
+        resolve_query
+
+        expect(Security::PipelineVulnerabilitiesFinder).to have_received(:new).with(pipeline: pipeline, params: params)
+      end
+    end
   end
 end

spec/controllers/jira_connect/events_controller_spec.rb

@@ -66,19 +66,19 @@ RSpec.describe JiraConnect::EventsController do
         request.headers['Authorization'] = "JWT #{auth_token}"
       end
 
-      subject { post :uninstalled }
+      subject(:post_uninstalled) { post :uninstalled }
 
       context 'when JWT is invalid' do
         let(:auth_token) { 'invalid_token' }
 
         it 'returns 403' do
-          subject
+          post_uninstalled
 
           expect(response).to have_gitlab_http_status(:forbidden)
         end
 
         it 'does not delete the installation' do
-          expect { subject }.not_to change { JiraConnectInstallation.count }
+          expect { post_uninstalled }.not_to change { JiraConnectInstallation.count }
         end
       end
 
@@ -87,8 +87,27 @@ RSpec.describe JiraConnect::EventsController do
           Atlassian::Jwt.encode({ iss: installation.client_key, qsh: qsh }, installation.shared_secret)
         end
 
-        it 'deletes the installation' do
-          expect { subject }.to change { JiraConnectInstallation.count }.by(-1)
+        let(:jira_base_path) { '/-/jira_connect' }
+        let(:jira_event_path) { '/-/jira_connect/events/uninstalled' }
+
+        it 'calls the DestroyService and returns ok in case of success' do
+          expect_next_instance_of(JiraConnectInstallations::DestroyService, installation, jira_base_path, jira_event_path) do |destroy_service|
+            expect(destroy_service).to receive(:execute).and_return(true)
+          end
+
+          post_uninstalled
+
+          expect(response).to have_gitlab_http_status(:ok)
+        end
+
+        it 'calls the DestroyService and returns unprocessable_entity in case of failure' do
+          expect_next_instance_of(JiraConnectInstallations::DestroyService, installation, jira_base_path, jira_event_path) do |destroy_service|
+            expect(destroy_service).to receive(:execute).and_return(false)
+          end
+
+          post_uninstalled
+
+          expect(response).to have_gitlab_http_status(:unprocessable_entity)
         end
       end
     end

spec/services/jira_connect_installations/destroy_service_spec.rb

+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe JiraConnectInstallations::DestroyService do
+  describe '.execute' do
+    it 'creates an instance and calls execute' do
+      expect_next_instance_of(described_class, 'param1', 'param2', 'param3') do |destroy_service|
+        expect(destroy_service).to receive(:execute)
+      end
+
+      described_class.execute('param1', 'param2', 'param3')
+    end
+  end
+
+  describe '#execute' do
+    let!(:installation) { create(:jira_connect_installation) }
+    let(:jira_base_path) { '/-/jira_connect' }
+    let(:jira_event_path) { '/-/jira_connect/events/uninstalled' }
+
+    subject { described_class.new(installation, jira_base_path, jira_event_path).execute }
+
+    it { is_expected.to be_truthy }
+
+    it 'deletes the installation' do
+      expect { subject }.to change(JiraConnectInstallation, :count).by(-1)
+    end
+
+    context 'and the installation has an instance_url set' do
+      let!(:installation) { create(:jira_connect_installation, instance_url: 'http://example.com') }
+
+      it { is_expected.to be_truthy }
+
+      it 'schedules a ForwardEventWorker background job and keeps the installation' do
+        expect(JiraConnect::ForwardEventWorker).to receive(:perform_async).with(installation.id, jira_base_path, jira_event_path)
+
+        expect { subject }.not_to change(JiraConnectInstallation, :count)
+      end
+    end
+  end
+end

spec/workers/jira_connect/forward_event_worker_spec.rb

+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe JiraConnect::ForwardEventWorker do
+  describe '#perform' do
+    let!(:jira_connect_installation) { create(:jira_connect_installation, instance_url: self_managed_url, client_key: client_key, shared_secret: shared_secret) }
+    let(:base_path) { '/-/jira_connect' }
+    let(:event_path) { '/-/jira_connect/events/uninstalled' }
+
+    let(:self_managed_url) { 'http://example.com' }
+    let(:base_url) { self_managed_url + base_path }
+    let(:event_url) { self_managed_url + event_path }
+
+    let(:client_key) { '123' }
+    let(:shared_secret) { '123' }
+
+    subject { described_class.new.perform(jira_connect_installation.id, base_path, event_path) }
+
+    it 'forwards the event including the auth header and deletes the installation' do
+      stub_request(:post, event_url)
+
+      expect(Atlassian::Jwt).to receive(:create_query_string_hash).with(event_url, 'POST', base_url).and_return('some_qsh')
+      expect(Atlassian::Jwt).to receive(:encode).with({ iss: client_key, qsh: 'some_qsh' }, shared_secret).and_return('auth_token')
+      expect { subject }.to change(JiraConnectInstallation, :count).by(-1)
+
+      expect(WebMock).to have_requested(:post, event_url).with(headers: { 'Authorization' => 'JWT auth_token' })
+    end
+
+    context 'when installation does not exist' do
+      let(:jira_connect_installation) { instance_double(JiraConnectInstallation, id: -1) }
+
+      it 'does nothing' do
+        expect { subject }.not_to change(JiraConnectInstallation, :count)
+      end
+    end
+
+    context 'when installation does not have an instance_url' do
+      let!(:jira_connect_installation) { create(:jira_connect_installation) }
+
+      it 'forwards the event including the auth header' do
+        expect { subject }.to change(JiraConnectInstallation, :count).by(-1)
+
+        expect(WebMock).not_to have_requested(:post, '*')
+      end
+    end
+
+    context 'when it fails to forward the event' do
+      it 'still deletes the installation' do
+        allow(Gitlab::HTTP).to receive(:post).and_raise(StandardError)
+
+        expect { subject }.to raise_error(StandardError).and change(JiraConnectInstallation, :count).by(-1)
+      end
+    end
+  end
+end